Check API compatibility workflow (google/gson)
The Check API compatibility workflow from google/gson, explained and optimized by Latchkey.
CI health: C - fair
Point runs-on at Latchkey and get run de-duplication, job timeouts, self-healing for flaky steps, and up to 58% lower cost, applied automatically.
What it does
This is the Check API compatibility workflow from the google/gson repository, a real project running GitHub Actions. It is shown here with attribution under its Apache-2.0 license.
Below, Latchkey shows a faster, safer version produced by its optimization engine.
The workflow
# This workflow makes sure that a pull request does not make any incompatible changes
# to the public API of Gson
name: Check API compatibility
on: pull_request
permissions:
contents: read # to fetch code (actions/checkout)
env:
# Common Maven arguments
MAVEN_ARGS: --show-version --batch-mode --no-transfer-progress
jobs:
check-api-compatibility:
runs-on: ubuntu-latest
# This setup tries to determine API incompatibility only for the changes introduced by the
# pull request. It does this by first checking out the 'old' version and installing it into
# the local Maven repository before then using japicmp to compare it to the current changes.
#
# Alternatively it would also be possible to compare against the last release version instead.
#
# Both approaches have their advantages and disadvantages, see description of
# https://github.com/google/gson/pull/2692 for details.
steps:
- name: Check out old version
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
with:
ref: ${{ github.event.pull_request.base.sha }}
path: 'gson-old-japicmp'
- name: Set up JDK
uses: actions/setup-java@be666c2fcd27ec809703dec50e508c2fdc7f6654 # v5.2.0
with:
distribution: 'temurin'
java-version: '17'
cache: 'maven'
- name: Build old version
run: |
cd gson-old-japicmp
# Set dummy version
mvn org.codehaus.mojo:versions-maven-plugin:2.16.2:set "-DnewVersion=0.0.0-JAPICMP-OLD"
# Install artifacts with dummy version in local repository; used later by Maven plugin for comparison
mvn install -Dmaven.test.skip --projects '!metrics,!test-graal-native-image,!test-jpms,!test-shrinker'
- name: Check out new version
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Check API compatibility
id: check-compatibility
run: |
mvn package japicmp:cmp --fail-at-end -Dmaven.test.skip --projects '!extras,!metrics,!test-graal-native-image,!test-jpms,!test-shrinker'
- name: Upload API differences artifacts
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
# Run on workflow success (in that case differences report might include added methods and classes)
# or when API compatibility check failed
if: success() || ( failure() && steps.check-compatibility.outcome == 'failure' )
with:
name: api-differences
path: |
**/japicmp/default-cli.html
**/japicmp/default-cli.diff
# Plugin should always have created report files (though they might be empty)
if-no-files-found: error
The same workflow, on Latchkey
Removes redundant runs and caps runaway jobs. Added and changed lines are highlighted.
# This workflow makes sure that a pull request does not make any incompatible changes # to the public API of Gson name: Check API compatibility on: pull_request permissions: contents: read # to fetch code (actions/checkout) env: # Common Maven arguments MAVEN_ARGS: --show-version --batch-mode --no-transfer-progress concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true jobs: check-api-compatibility: timeout-minutes: 30 runs-on: latchkey-small # This setup tries to determine API incompatibility only for the changes introduced by the # pull request. It does this by first checking out the 'old' version and installing it into # the local Maven repository before then using japicmp to compare it to the current changes. # # Alternatively it would also be possible to compare against the last release version instead. # # Both approaches have their advantages and disadvantages, see description of # https://github.com/google/gson/pull/2692 for details. steps: - name: Check out old version uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 with: ref: ${{ github.event.pull_request.base.sha }} path: 'gson-old-japicmp' - name: Set up JDK uses: actions/setup-java@be666c2fcd27ec809703dec50e508c2fdc7f6654 # v5.2.0 with: distribution: 'temurin' java-version: '17' cache: 'maven' - name: Build old version run: | cd gson-old-japicmp # Set dummy version mvn org.codehaus.mojo:versions-maven-plugin:2.16.2:set "-DnewVersion=0.0.0-JAPICMP-OLD" # Install artifacts with dummy version in local repository; used later by Maven plugin for comparison mvn install -Dmaven.test.skip --projects '!metrics,!test-graal-native-image,!test-jpms,!test-shrinker' - name: Check out new version uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 - name: Check API compatibility id: check-compatibility run: | mvn package japicmp:cmp --fail-at-end -Dmaven.test.skip --projects '!extras,!metrics,!test-graal-native-image,!test-jpms,!test-shrinker' - name: Upload API differences artifacts uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 # Run on workflow success (in that case differences report might include added methods and classes) # or when API compatibility check failed if: success() || ( failure() && steps.check-compatibility.outcome == 'failure' ) with: name: api-differences path: | **/japicmp/default-cli.html **/japicmp/default-cli.diff # Plugin should always have created report files (though they might be empty) if-no-files-found: error
What changed
- Run on Latchkey managed runners with one line (
runs-on), which apply the fixes below automatically and self-heal transient failures. This example useslatchkey-small; pick the runner size that fits the job. - Cancel superseded runs when a branch or PR gets a newer push.
- Add a job timeout so a hung step cannot burn hours of runner time.
What Latchkey heals here
This workflow has steps that commonly fail on transient issues (network, registries, flaky browsers). On Latchkey managed runners they are detected, retried, and self-healed instead of failing your build:
- Dependency installs
This workflow runs 1 job per trigger. On Latchkey the same minutes cost up to 58% less than GitHub-hosted, with zero queue time.