We upgrade our CI and release GitHub Actions workflows to use the latest Ubuntu runners, which run Ubuntu LTS 22.04 at present, and the latest available versions of all Actions steps.

As testing the release.yml workflow is not convenient without generating a release, it has instead been run successfully on a separate, private repository cloned from this one.

Ubuntu Runners

In commit d6b34fa of PR #4437 we switched our CI and release GitHub Actions workflows to explicitly use the then-latest Ubuntu LTS version 20.04 in order to support ARM64 builds, as these required a version of Go (specifically 1.16) which was not available on the ubuntu-latest Actions runners at the time because they still ran Ubuntu LTS version 18.04.

However, ubuntu-latest Actions runners now use an even newer LTS version of Ubuntu, 22.04, than the one we have explicitly identified, so we can return to specifying ubuntu-latest for our CI and release builds.

Actions and Checkouts

In PR #5236 we upgraded our CI and release workflows to use the latest recommended ruby/setup-ruby@v1 GitHub Actions step to install Ruby and its dependencies.

We now update our other Actions steps to their respective latest versions as well:

  actions/checkout:           v1 -> v3
  actions/download-artifact:  v1 -> v3
  actions/setup-go:           v2 -> v3
  actions/upload-artifact:    v1 -> v3
  docker/setup-qemu-action:   v1 -> v2

Artifact Download Paths

As of v2 of the actions/download-artifact Action, downloaded assets are not placed in a new subdirectory created with the name from the step's name argument, but in the current working directory instead. We want to retain the previous behaviour so we add a path argument with the same name as each of the macos-assets and windows-assets download steps.

Fetching Full Clones

By default, the actions/checkout Action (as of v2) performs a Git fetch with a --depth=1 option, so a shallow clone is made. As a result, when our Makefile calls git describe HEAD to set its VERSION variable, no tags are available and Git responds with an error message.

Many of our workflow jobs succeed despite logging that error, including the build-docker and build-docker-cross jobs in both our CI and Release workflows. (The Docker builds create upload artifacts with the valid filenames despite the lack of any tags because they rely on the Git LFS version strings in our debian/changelog file and in our binary; the rpm/build_rpms.bsh script builds a binary just to run git-lfs version and determine the version string from its output.)

However, our workflow jobs which run the make release command fail outright in the absence of any Git tags, as they search for build artifacts using filenames constructed with the empty VERSION variable, such as git-lfs-windows-amd64-.zip. When no files are found, the tar command fails, halting the job. This affects both the build-default job in our CI workflow (for Linux and macOS), and all of build-main, build-macos, and build-windows jobs in our Release workflow.

To resolve this in the case of a PR or other push to a branch, we set a fetch-depth value of 0 for our actions/checkout@v3 steps, which downloads the full Git history and all tags. This is somewhat more expensive than a shallow clone, but our project's history is not excessively large.

Temporary Workaround for Incorrect Tag Fetches

Due to the GitHub Actions bug documented in actions/checkout#882, though, this resolution is insufficient in the case of a push to a tag. At present, when fetch-depth is 0, the actions/checkout@v3 incorrectly determines the SHA of an annotated tag to be the SHA of its associated commit, and then proceeds as if the tag had been updated on the server since the Action was started, and so rewrites the tag locally to refer to the commit SHA. This has the effect of making the local tag into a lightweight tag, which git describe then ignores (since we don't pass the --tags option to it).

As a temporary fix for this problem, we add a step after the actions/checkout@v3 step which updates the local tag again to match the remote one. We only run this step when the pushed reference was a tag, because on a branch push it would fail as Git would refuse to update the currently checked-out branch. In our Release workflow, since it only runs on pushes to tags, we can run this step unconditionally. (We could also continue to use the default fetch-depth of 1 for the actions/checkout@v3 step, since we always subsequently fetch the relevant tag, but to be consistent and to avoid future issues once actions/checkout#882 is fixed upstream, we do not do so.)

/cc actions/checkout#882
/cc #5228