Merge pull request #35 from thomaseizinger/release/2.0.0

Author: thomaseizinger

.github/workflows/CI.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,34 +32,35 @@ 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:
+        env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          head: release/${{ env.RELEASE_VERSION }}
+        with:
+          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.
+          title: Release version ${{ github.event.inputs.version }}
+          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 }}.
+            This PR was created in response to a manual trigger of the release workflow here: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}.
             I've updated the changelog and bumped the versions in the manifest files in this commit: ${{ steps.make-commit.outputs.commit }}.
 
             Merging this PR will create a GitHub release and upload any assets that are created as part of the release build.

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

@@ -19,30 +19,15 @@ jobs:
           BRANCH_NAME="${{ github.event.pull_request.head.ref }}"
           VERSION=${BRANCH_NAME#release/}
 
-          echo "::set-env name=RELEASE_VERSION::$VERSION"
+          echo "RELEASE_VERSION=$VERSION" >> $GITHUB_ENV
 
       - name: Extract version from branch name (for hotfix branches)
         if: startsWith(github.event.pull_request.head.ref, 'hotfix/')
         run: |
           BRANCH_NAME="${{ github.event.pull_request.head.ref }}"
           VERSION=${BRANCH_NAME#hotfix/}
 
-          echo "::set-env name=RELEASE_VERSION::$VERSION"
-
-      # Unfortunately, GitHub doesn't trigger events for actions that have been taken by a GitHub action.
-      # This means we cannot use `Fixes #issue_number.` in the body of the PR to close the release issue after the branch is merged.
-      # Hence, we close it here "manually"
-      - name: Close release issue
-        run: |
-          RELEASE_ISSUE_URL=$(curl https://api.github.com/repos/${{ github.repository }}/issues\?labels=release\&state=open | jq -r '.[0].url')
-
-          curl \
-            -X PATCH \
-            -H 'Accept: application/vnd.github.v3+json' \
-            -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
-            -H "Content-Type: application/json" \
-            $RELEASE_ISSUE_URL \
-            -d '{"state":"closed"}'
+          echo "RELEASE_VERSION=$VERSION" >> $GITHUB_ENV
 
       - name: Create Release
         uses: thomaseizinger/create-release@1.0.0
@@ -55,15 +40,16 @@ jobs:
           draft: false
           prerelease: false
 
-      - name: Merge release into dev branch
+      - name: Merge master into dev branch
         uses: thomaseizinger/create-pull-request@1.0.0
-        with:
+        env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          head: release/${{ env.RELEASE_VERSION }}
+        with:
+          head: master
           base: dev
-          title: Merge release ${{ env.RELEASE_VERSION }} into dev branch
+          title: Merge master into dev branch
           body: |
-            This PR merges the release branch for ${{ env.RELEASE_VERSION }} back into dev.
+            This PR merges the master branch back into dev.
             This happens to ensure that the updates that happend on the release branch, i.e. CHANGELOG and manifest updates are also present on the dev branch.
 
       # if needed, you can checkout the latest master here, build artifacts and publish / deploy them somewhere

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

@@ -7,6 +7,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [2.0.0] - 2020-10-17
+
+### 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.
+-   Merge `master` in `dev` after a release branch is merged.
+    Previously, we used to merge the `release` branch back into `dev`.
+    However, this caused some issues because the actual merge commit was not present in the `dev` branch.
+    It also prevented use of the "automatically delete head branch" feature of GitHub which works well together with the "PR retargeting" feature.
+
 ## [1.4.0] - 2020-02-22
 
 ### Added
@@ -43,7 +54,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 -   Everything since the beginning!
 
-[Unreleased]: https://github.com/thomaseizinger/github-action-gitflow-release-workflow/compare/1.4.0...HEAD
+[Unreleased]: https://github.com/thomaseizinger/github-action-gitflow-release-workflow/compare/2.0.0...HEAD
+
+[2.0.0]: https://github.com/thomaseizinger/github-action-gitflow-release-workflow/compare/1.4.0...2.0.0
 
 [1.4.0]: https://github.com/thomaseizinger/github-action-gitflow-release-workflow/compare/1.3.0...1.4.0
 

.travis.yml

@@ -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:
@@ -18,7 +18,10 @@ The automation will do the following things:
 
 ## Design
 
-I've written a blog post that describes the technical design in detail here: https://blog.eizinger.io/12274/using-github-actions-to-automate-gitflow-style-releases
+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.
 

CHANGELOG.md

@@ -1,13 +1,7 @@
 {
   "name": "github-action-gitflow-release-workflow",
-  "version": "1.4.0",
+  "version": "2.0.0",
   "main": "index.js",
   "author": "Thomas Eizinger <thomas@eizinger.io>",
-  "license": "MIT",
-  "scripts": {
-    "test": "jest"
-  },
-  "devDependencies": {
-    "jest": "^24.9.0"
-  }
+  "license": "MIT"
 }