Convert draft-new-release workflow to use workflow_dispatch

Author: thomaseizinger

.github/workflows/draft-new-release.yml

@@ -1,34 +1,26 @@
 name: "Draft new release"
 
 on:
-  issues:
-    types: [opened, labeled]
+  workflow_dispatch:
+    inputs:
+      version:
+        description: 'The version you want to release.'
+        required: true
 
 jobs:
   draft-new-release:
     name: "Draft a new release"
     runs-on: ubuntu-latest
-    # Only run for issues with a specific title and label. Not strictly required but makes finding the release issue again later easier.
-    # There is also a whitelist that you may want to use to restrict, who can trigger this workflow.
-    # Unfortunately, we cannot create an array on the fly, so the whitelist is just comma-separated.
-    if: startsWith(github.event.issue.title, 'Release version') && contains(github.event.issue.labels.*.name, 'release') && contains('thomaseizinger,yourusername', github.event.issue.user.login)
     steps:
       - uses: actions/checkout@v2
 
-      - name: Extract version from issue title
-        run: |
-          TITLE="${{ github.event.issue.title }}"
-          VERSION=${TITLE#Release version }
-
-          echo "::set-env name=RELEASE_VERSION::$VERSION"
-
       - name: Create release branch
-        run: git checkout -b release/${{ env.RELEASE_VERSION }}
+        run: git checkout -b release/${{ github.event.inputs.version }}
 
       - name: Update changelog
         uses: thomaseizinger/keep-a-changelog-new-release@1.1.0
         with:
-          version: ${{ env.RELEASE_VERSION }}
+          version: ${{ github.event.inputs.version }}
 
       # In order to make a commit, we need to initialize a user.
       # You may choose to write something less generic here if you want, it doesn't matter functionality wise.
@@ -40,32 +32,32 @@ jobs:
       # This step will differ depending on your project setup
       # Fortunately, yarn has a built-in command for doing this!
       - name: Bump version in package.json
-        run: yarn version --new-version ${{ env.RELEASE_VERSION }} --no-git-tag-version
+        run: yarn version --new-version ${{ github.event.inputs.version }} --no-git-tag-version
 
       - name: Commit changelog and manifest files
         id: make-commit
         run: |
           git add CHANGELOG.md package.json
-          git commit --message "Prepare release ${{ env.RELEASE_VERSION }}"
+          git commit --message "Prepare release ${{ github.event.inputs.version }}"
 
           echo "::set-output name=commit::$(git rev-parse HEAD)"
 
       - name: Push new branch
-        run: git push origin release/${{ env.RELEASE_VERSION }}
+        run: git push origin release/${{ github.event.inputs.version }}
 
       - name: Create pull request
         uses: thomaseizinger/create-pull-request@1.0.0
         with:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          head: release/${{ env.RELEASE_VERSION }}
+          head: release/${{ github.event.inputs.version }}
           base: master
           title: ${{ github.event.issue.title }}
-          reviewers: ${{ github.event.issue.user.login }} # By default, we request a review from the person who opened the issue. You can replace this with a static list of users.
+          reviewers: ${{ github.actor }} # By default, we request a review from the person who triggered the workflow.
           # Write a nice message to the user.
           # We are claiming things here based on the `publish-new-release.yml` workflow.
           # You should obviously adopt it to say the truth depending on your release workflow :)
           body: |
-            Hi @${{ github.event.issue.user.login }}!
+            Hi @${{ github.actor }}!
 
             This PR was created in response to this release issue: #${{ github.event.issue.number }}.
             I've updated the changelog and bumped the versions in the manifest files in this commit: ${{ steps.make-commit.outputs.commit }}.

CHANGELOG.md

@@ -7,6 +7,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Changed
+
+-   Use `workflow_dispatch` instead of opening an issue as the initial trigger of the release.
+Not only is this more convenient to use, it also fixes a security vulnerability that may have allowed users without write access to execute arbitrary code within the context of the repositories GitHub action.
+
 ## [1.4.0] - 2020-02-22
 
 ### Added

README.md

@@ -7,7 +7,7 @@ You are welcome to use it for inspiration for your own release workflows or mayb
 
 If you are using the workflows as they are in this repository, there are only two manual steps for releasing a new version:
 
-1. Create a ticket that is titled "Release version x.y.z" and label it with "release".
+1. Trigger the "Draft new release" workflow through the "Actions" tab.
 2. Merge the PR that is created for you.
 
 The automation will do the following things:
@@ -20,6 +20,9 @@ The automation will do the following things:
 
 I've written a blog post that describes the technical design in detail here: https://blog.eizinger.io/12274/using-github-actions-and-gitflow-to-automate-your-release-process
 
+NOTE: The workflows and actions in this repository were changed since the blogpost was published.
+Please see the CHANGELOG.md for a detailed summary.
+
 The idea of these workflows is to automate all the tedious aspects of releases while still allowing manual intervention if necessary and control over crucial aspects.
 
 I think I've achieved this by doing the following: