Release workflow (fortio/fortio)

The Release workflow from fortio/fortio, explained and optimized by Latchkey.

CI health: C - fair

Point runs-on at Latchkey and get run de-duplication, job timeouts, SHA-pinned actions, self-healing for flaky steps, and up to 58% lower cost, applied automatically.

Grade your own workflow free or run it on Latchkey →

Source: fortio/fortio.github/workflows/main.ymlLicense Apache-2.0View source

What it does

This is the Release workflow from the fortio/fortio 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

workflow (.yml)

name: Release

permissions:
  actions: read
  contents: write
  packages: write

on:
  push:
    tags:
      # so a vX.Y.Z-test1 doesn't trigger build
      - 'v[0-9]+.[0-9]+.[0-9]+'
      - 'v[0-9]+.[0-9]+.[0-9]+-pre*'

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      - name: Common Setup
        id: common_setup
        uses: fortio/workflows/.github/actions/common_setup@main
        with:
          DOCKER_USER: ${{ secrets.DOCKER_USER }}
          DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
      - name: Available platforms
        run: |
          echo "Build platforms: ${{ steps.common_setup.outputs.platforms }}"
      - name: Build
        id: build
        run: |
          make info
          make release
          VERSION=$(make echo-version)
          echo "VERSION=${VERSION}" >> $GITHUB_ENV
          PACKAGE_VERSION=$(make echo-package-version)
          echo "Version $VERSION, Package version $PACKAGE_VERSION"

      - name: Build and push Docker image
        uses: docker/build-push-action@f9f3042f7e2789586610d6e8b85c8f03e5195baf # pin@v5
        with:
          context: .
          platforms: linux/amd64,linux/arm64,linux/ppc64le,linux/s390x
          push: true
          tags: fortio/fortio:${{ env.VERSION }}, fortio/fortio:latest

      - name: Create Release
        id: create_release
        # Need to find a replacement not using set-output
        uses: actions/create-release@0cb9c9b65d5d1901c1f53e5e66eaf4afd303e70e # pin@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
        with:
          tag_name: ${{ github.ref }}
          release_name: Fortio ${{ env.VERSION }}
          draft: true

      - name: Upload release artifacts
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          tag_name="${GITHUB_REF##*/}"
          echo "will use tag_name=$tag_name"
          # tends to fail and not find the release somehow; add a small sleep... (yuck)
          sleep 10
          gh release upload "${tag_name}" release/*.{tgz,zip,rpm,deb,gz}

The same workflow, on Latchkey

Removes redundant runs and caps runaway jobs. Added and changed lines are highlighted.

name: Release
 
permissions:
  actions: read
  contents: write
  packages: write
 
on:
  push:
    tags:
      # so a vX.Y.Z-test1 doesn't trigger build
      - 'v[0-9]+.[0-9]+.[0-9]+'
      - 'v[0-9]+.[0-9]+.[0-9]+-pre*'
 
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
 
jobs:
  # This workflow contains a single job called "build"
  build:
    timeout-minutes: 30
    # The type of runner that the job will run on
    runs-on: latchkey-small
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      - name: Common Setup
        id: common_setup
        uses: fortio/workflows/.github/actions/common_setup@main
        with:
          DOCKER_USER: ${{ secrets.DOCKER_USER }}
          DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
      - name: Available platforms
        run: |
          echo "Build platforms: ${{ steps.common_setup.outputs.platforms }}"
      - name: Build
        id: build
        run: |
          make info
          make release
          VERSION=$(make echo-version)
          echo "VERSION=${VERSION}" >> $GITHUB_ENV
          PACKAGE_VERSION=$(make echo-package-version)
          echo "Version $VERSION, Package version $PACKAGE_VERSION"
 
      - name: Build and push Docker image
        uses: docker/build-push-action@f9f3042f7e2789586610d6e8b85c8f03e5195baf # pin@v5
        with:
          context: .
          platforms: linux/amd64,linux/arm64,linux/ppc64le,linux/s390x
          push: true
          tags: fortio/fortio:${{ env.VERSION }}, fortio/fortio:latest
 
      - name: Create Release
        id: create_release
        # Need to find a replacement not using set-output
        uses: actions/create-release@0cb9c9b65d5d1901c1f53e5e66eaf4afd303e70e # pin@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
        with:
          tag_name: ${{ github.ref }}
          release_name: Fortio ${{ env.VERSION }}
          draft: true
 
      - name: Upload release artifacts
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          tag_name="${GITHUB_REF##*/}"
          echo "will use tag_name=$tag_name"
          # tends to fail and not find the release somehow; add a small sleep... (yuck)
          sleep 10
          gh release upload "${tag_name}" release/*.{tgz,zip,rpm,deb,gz}

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 uses latchkey-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.

1 third-party action is referenced by a movable tag. Pin it to the commit SHA (Latchkey resolves and applies this automatically) so a repointed tag cannot change what runs.

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:

Container pulls and builds

This workflow runs 1 job per trigger. On Latchkey the same minutes cost up to 58% less than GitHub-hosted, with zero queue time.

Actions used in this workflow

docker/build-push-action