Replace automatic releases with manual trigger

We used Shipkit for a continuous delivery model, where every change
on the `master` branch (for example when merging a pull request)
triggered a release build that published a new version if specific
criteria were met. Because this project's development often happens
in sporadic bursts, where a lot of PRs are merged within a few hours,
this approach lead to some superfluous releases. We also weren't 100%
successful in predicting whether Shipkit would make a release and so
we started cluttering our commit messages with `[ci skip-release]`,
which was a bit annoying. Hence the change to a new release model.

With this change, we no longer release on every commit to `master`.
Instead, releases must be triggered manually by pushing a tag
`releaseTrigger` to `master`. GitHub Actions will then tell Shipkit
to do its thing and afterwards delete the tag.

See issue #193 for a discussion of other option to trigger a release.

This change also triggers a site build on successful release, which
finishes the move from Travis CI to GitHub actions.

Closes: #193, #192
PR: #256

.github/workflows/actions.yml

@@ -52,41 +52,3 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           SONAR_TOKEN: "61ab2579215aa8a0024a2f9368fc1298fdecfd18"
         run: ./gradlew jacocoTestReport sonarqube --stacktrace -i
-
-  deploy:
-    needs: build
-    runs-on: ubuntu-latest
-    name: Deploy with Shipkit
-    if: github.ref == 'refs/heads/master'
-    steps:
-      - name: Sanitize Branch
-        uses: frabert/replace-string-action@master
-        id: gitbranch
-        with:
-          pattern: 'refs/heads/(.*)'
-          string: "${{ github.ref }}"
-          replace-with: '$1'
-      - uses: actions/checkout@v2
-      - name: Setup java
-        uses: actions/setup-java@v1
-        with:
-          java-version: 8
-      - name: Perform Release
-        uses: eskatos/gradle-command-action@v1
-        env:
-          TRAVIS_BRANCH: ${{ steps.gitbranch.outputs.replaced }}
-          TRAVIS_COMMIT_MESSAGE: ${{ github.event.head_commit.message }}
-          TRAVIS_PULL_REQUEST: ${{ github.event_name == 'pull_request' }}
-          GH_WRITE_TOKEN: ${{ secrets.GH_WRITE_TOKEN }}
-          BINTRAY_USER_NAME: ${{ secrets.BINTRAY_USER_NAME }}
-          BINTRAY_API_KEY: ${{ secrets.BINTRAY_API_KEY }}
-          NEXUS_TOKEN_USERNAME: ${{ secrets.NEXUS_TOKEN_USERNAME }}
-          NEXUS_TOKEN_PASSWORD: ${{ secrets.NEXUS_TOKEN_PASSWORD }}
-        with:
-          arguments: ciPerformRelease
-
-  #     - name: Update Page
-  #       uses: eskatos/gradle-command-action@v1
-  #       with:
-  #         arguments: triggerSiteBuild -P travisApiToken=${{ secrets.TRAVIS_API_TOKEN }} --stacktrace
-

.github/workflows/releaseTrigger.yml

@@ -0,0 +1,49 @@
+
+name: Release
+
+on:
+  create:
+    tags:
+      - 'releaseTrigger'
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    name: releasing
+    steps:
+      - name: Wait For Other Builds To Succeed
+        # This steps waits for all github actions builds to suceed, before continuing.
+        # Currently we only have our default action, so we can ensure, 
+        # that our codebase builds correctly
+        uses: jitterbit/await-check-suites@v1
+        with:
+          appSlugFilter: 'github-actions'
+          timeoutSeconds: '300'
+      - uses: actions/checkout@v2
+      - name: Setup java
+        uses: actions/setup-java@v1
+        with:
+          java-version: 8
+      - name: Perform Release
+        uses: eskatos/gradle-command-action@v1
+        env:
+          # shipkit does not support GitHub Actions for now, hence that we simulate to be Travis CI
+          TRAVIS_BRANCH: master
+          TRAVIS_COMMIT_MESSAGE: <no commit message, not needed, we do not care about them, if we trigger or not>
+          TRAVIS_PULL_REQUEST: false
+          GH_WRITE_TOKEN: ${{ secrets.GH_WRITE_TOKEN }}
+          BINTRAY_USER_NAME: ${{ secrets.BINTRAY_USER_NAME }}
+          BINTRAY_API_KEY: ${{ secrets.BINTRAY_API_KEY }}
+          NEXUS_TOKEN_USERNAME: ${{ secrets.NEXUS_TOKEN_USERNAME }}
+          NEXUS_TOKEN_PASSWORD: ${{ secrets.NEXUS_TOKEN_PASSWORD }}
+        with:
+          arguments: ciPerformRelease
+      - name: Delete Tag
+        if: ${{ always() }}
+        run: git push --delete origin releaseTrigger
+      - name: Trigger Website Build
+        uses: peter-evans/repository-dispatch@v1
+        with:
+          token: ${{ secrets.GH_WRITE_TOKEN }}
+          repository: junit-pioneer/junit-pioneer.github.io
+          event-type: triggerSiteBuild

CONTRIBUTING.md

@@ -285,14 +285,17 @@ Follow these steps when updating JUnit 5:
 
 ## Publishing
 
-Like [Mockito](http://mockito.org/), JUnit Pioneer implements a continuous delivery model using [Shipkit](http://shipkit.org/) and [GitHub Actions](https://github.com/features/actions/).
-Every change on the `master` branch (for example when merging a pull request) triggers a release build that publishes a new version if the following criteria are met:
+JUnit Pioneer uses [Shipkit](http://shipkit.org/) and [GitHub Actions](https://github.com/features/actions/) to automate the release process, but unlike Shipkit's default we don't release on every commit to `master`.
+Instead, releases must be triggered manually:
 
-- the commit message doesn't contain `[ci skip-release]`
-- all checks (e.g. tests) are successful
-- at least one main artifact (that includes `...-source.jar` and `...-javadoc.jar`) has changed
+1. make sure that the file [`version-properties`](version.properties) defines the correct version (see next section)
+2. push a tag `releaseTrigger` to `master`
+
+GitHub Actions will then tell Shipkit to do its thing and afterwards delete the tag.
+The tag is always deleted, even if the release fails, so it is easy to trigger another one.
 
 Every new version is published to the `junit-pioneer/maven` Bintray repository as well as to Maven Central and JCenter.
+This also triggers a website build - [see its `README.md`](https://github.com/junit-pioneer/junit-pioneer.github.io) for more information.
 
 ### Versioning
 
@@ -310,6 +313,18 @@ Since each non-trivial change is developed in a PR, this is the place to discuss
 If it is, the PR needs to update `version-properties` to the next minor version.
 Note that the feature's Javadoc needs to reference the same version in its `@since` tag.
 
+### Background
+
+Like [Mockito](http://mockito.org/), JUnit Pioneer used Shipkit for a continuous delivery model, where every change on the `master` branch (for example when merging a pull request) triggered a release build that published a new version if the following criteria were met:
+
+- the commit message doesn't contain `[ci skip-release]`
+- all checks (e.g. tests) are successful
+- at least one main artifact (that includes `...-source.jar` and `...-javadoc.jar`) has changed
+
+Because this project's development often happens in sporadic bursts, where a lot of PRs are merged within a few hours, this approach lead to some superfluous releases.
+We also weren't 100% successful in predicting whether Shipkit would make a release and so we started cluttering our commit messages with `[ci skip-release]`, which was a bit annoying.
+Hence the change to the model described above.
+
 
 ## Pioneer Maintainers