Combine test & release workflows into single CI workflow

This commit is contained in:
Matthew Leather 2021-09-03 15:57:59 +10:00 committed by GitHub
parent 1f5ef7c9c1
commit a35fa3e61c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 100 additions and 96 deletions

View File

@ -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
uses: actions/setup-java@v2.2.0
- name: Set up java
uses: actions/setup-java@v2.3.0
with:
java-version: 8
distribution: 'temurin'
distribution: temurin
cache: maven
- 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-
# 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
# Downloading all the dependencies is very log spammy, so we do this in its own step.
- name: Prime maven cache
run: mvn --batch-mode dependency:go-offline
- name: Run tests with Maven
run: mvn -B test --file pom.xml
# POM version is usually a -SNAPSHOT at this point, if this is a release then we use the version derived from the tag
- 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"

View File

@ -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

19
docs/releasing.md Normal file
View File

@ -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