Combine test & release workflows into single CI workflow

.github/workflows/ci.yml

@@ -1,38 +1,100 @@
-name: tests
+name: CI
 
 on:
+  create:
   pull_request:
     types: [ opened, synchronize, reopened ]
   push:
     branches:
       - master
+  workflow_dispatch:
 
 jobs:
-  run_tests:
+  CI:
     runs-on: ubuntu-latest
     steps:
+      - name: Configure job
+        id: config
+        env:
+          ACTOR: ${{ github.actor }}
+          EVENT_ACTION: ${{ github.event.action }}
+          REF_TYPE: ${{ github.event.ref_type }}
+          REF: ${{ github.event.ref }}
+        run: |
+          cat <<-EOF
+            ::group::Debug Info
+            GITHUB_EVENT_NAME       : '${GITHUB_EVENT_NAME}'
+            EVENT_ACTION            : '${EVENT_ACTION}'
+            REF_TYPE                : '${REF_TYPE}'
+            REF                     : '${REF}'
+            ACTOR                   : '${ACTOR}'
+            GITHUB_REPOSITORY_OWNER : '${GITHUB_REPOSITORY_OWNER}'
+            ::endgroup::
+          EOF
+
+          # Do a release when a git tag starting with 'v' has been created by a suitable user.
+          # (We match against github.repository_owner as a kludge so that forked repos can release themselves when testing the workflow)
+
+          if [[ "${GITHUB_EVENT_NAME}" == "create" && \
+                "${REF_TYPE}" == "tag" && \
+                "${REF}" == v* && \
+                ( "${ACTOR}" == "arnaudroques" || "${ACTOR}" == "${GITHUB_REPOSITORY_OWNER}" ) \
+             ]]; then
+            echo "📣 This run will release '${REF}'"
+            echo "::set-output name=do_release::true"
+            echo "::set-output name=pom_version::${REF#v}"  # pom_version is the tag without the 'v' prefix
+          else
+            echo "This run will NOT make a release"
+          fi
+
       - name: Checkout the repository
         uses: actions/checkout@v2
 
-      - name: Set up JDK 8
+      - name: Set up java
-        uses: actions/setup-java@v2.2.0
+        uses: actions/setup-java@v2.3.0
         with:
           java-version: 8
-          distribution: 'temurin'
+          distribution: temurin
+          cache: maven
 
-      - name: Cache local Maven repository
+      # Downloading all the dependencies is very log spammy, so we do this in its own step.
-        uses: actions/cache@v2
+      - name: Prime maven cache
-        with:
-          path: ~/.m2/repository
-          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
-          restore-keys: |
-            ${{ runner.os }}-maven-
-
-      # Downloading all the dependencies is very log spammy so we do this in its own step.
-      # Also the cache is reused by the "release" workflow but the workflow here does not use all
-      # dependencies so without the priming step the cache will be missing some things.
-      - name: Prime Maven cache
         run: mvn --batch-mode dependency:go-offline
 
-      - name: Run tests with Maven
+      # POM version is usually a -SNAPSHOT at this point, if this is a release then we use the version derived from the tag
-        run: mvn -B test --file pom.xml
+      - name: Set POM version
+        if: steps.config.outputs.do_release == 'true'
+        env:
+          POM_VERSION: ${{ steps.config.outputs.pom_version }}
+        run: |
+          mvn --batch-mode versions:set "-DnewVersion=${POM_VERSION}"
+
+      # Compile / Test / Package are separate steps so the reason for any failure is more obvious in GitHub UI
+      - name: Compile
+        run: mvn --batch-mode compile
+
+      - name: Test
+        run: mvn --batch-mode test
+
+      - name: Package
+        run: mvn --batch-mode -Dmaven.test.skip=true package
+
+      - name: Upload jar artifacts
+        if: ${{ always() }}
+        uses: actions/upload-artifact@v2
+        with:
+          # Using github.run_number here to reduce confusion when downloading & comparing artifacts from several builds  
+          name: ${{ github.run_number }}-jars
+          path: target/*.jar
+
+      - name: Create release in GitHub
+        if: steps.config.outputs.do_release == 'true'
+        env:
+          GITHUB_TOKEN: ${{ github.token }}
+          POM_VERSION: ${{ steps.config.outputs.pom_version }}
+          TAG: ${{ github.event.ref }}
+        run: |
+          gh release create "${TAG}" \
+            "target/plantuml-${POM_VERSION}.jar" \
+            "target/plantuml-${POM_VERSION}-javadoc.jar" \
+            "target/plantuml-${POM_VERSION}-sources.jar"

.github/workflows/release.yml

@@ -1,77 +0,0 @@
-name: Release Artifacts
-
-on:
-  release:
-    # It seems that events are not fired for DRAFT Releases so for now this will only run after a
-    # release or pre-release is published.
-    #   https://github.community/t/github-actions-are-not-run-on-release-created/126316/3
-    #   https://github.community/t/created-trigger-doent-work-for-when-i-created-draft-release/158595
-    types: [published]
-
-env:
-  RELEASE_TAG: ${{ github.event.release.tag_name }}
-
-jobs:
-  build_and_upload_jar:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout the repository
-        uses: actions/checkout@v2
-        with:
-          ref: refs/tags/${{ env.RELEASE_TAG }}
-
-      # GitHub will show this as the user that uploaded the release assets.
-      # See https://github.com/actions/checkout/issues/13#issuecomment-724415212
-      - name: Configure Git
-        run: |
-          git config user.email '41898282+github-actions[bot]@users.noreply.github.com'
-          git config user.name  'github-actions[bot]'
-
-      - name: Setup Java
-        uses: actions/setup-java@v2.2.0
-        with:
-          java-version: 8
-          distribution: 'temurin'
-
-      # If this run stores a new cache then the next run will not be able to use it because this is a tag checkout :-(
-      # But a cache already created on the default branch (by the CI workflow) will be loaded here.
-      # See https://github.com/actions/cache/issues/344
-      - name: Cache local Maven repository
-        uses: actions/cache@v2
-        with:
-          path: ~/.m2/repository
-          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
-          restore-keys: |
-            ${{ runner.os }}-maven-
-
-      # The POM version is usually a -SNAPSHOT at this point so we set it to RELEASE_TAG.
-      - name: Set POM version
-        run: mvn --batch-mode versions:set "-DnewVersion=${RELEASE_TAG}"
-
-      # We are not skipping tests here.  They are half redundant because tests also run in the CI build
-      # but it's possible for a release to be accidentally created from a commit where tests do not pass so
-      # running them again here is useful (they do not take up much time).  This is a code smell suggesting
-      # the CI / Release process can be simplified.  But as a first attempt it is good enough :-)
-      - name: Build JAR
-        run: mvn --batch-mode -Dmaven.javadoc.skip=true -Dmaven.source.skip=true package
-
-      # See https://docs.github.com/en/rest/reference/repos#upload-a-release-asset
-      - name: Upload JAR
-        run: |
-          # upload_url with trailing "{..." removed
-          upload_url="$(echo '${{ github.event.release.upload_url }}' | sed 's/{.*//' )"
-
-          http_code=$(curl \
-            --url "${upload_url}?name=plantuml-${RELEASE_TAG}.jar" \
-            --header 'Accept: application/vnd.github.v3+json' \
-            --header 'Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
-            --header 'Content-Type: application/java-archive' \
-            --data-binary "@target/plantuml-${RELEASE_TAG}.jar" \
-            --silent \
-            --output target/response.json \
-            --write-out '%{http_code}')
-
-          echo "Server response ${http_code}:"
-          cat target/response.json
-
-          [ ${http_code} -eq 201 ] || exit 1

docs/releasing.md

@@ -0,0 +1,19 @@
+# GitHub Releases
+
+Creating a new [release][1] in GitHub is done as part of the [CI workflow][2]
+but only when the workflow run is for a new git tag beginning with a `v`.
+
+Tags [cannot][3] be part of a pull request, so you need to push directly to the `plantuml` repo, e.g.
+
+	git tag -a v1.2021.1 -m "version 1.2021.1"
+	git push origin v1.2021.1
+
+The release will only happen if the username making the push is matched in the CI `Configure job` step.
+
+# Releases Elsewhere 
+
+PlantUML is released to other places, currently that happens outside of GitHub and is not documented here.
+
+[1]: https://github.com/plantuml/plantuml/releases
+[2]: https://github.com/plantuml/plantuml/actions/workflows/ci.yml
+[3]: https://stackoverflow.com/questions/12278660/adding-tags-to-a-pull-request