Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
.github/workflows: upgrade all Actions versions
In commit b7fa3a5 of PR git-lfs#5236 we replaced the deprecated actions/setup-ruby@v1 GitHub Action in our CI and release workflows with the current ruby/setup-ruby@v1 Action. We now update our other Actions 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 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. 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 correct 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. 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, 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.)
- Loading branch information
1 parent
da481bf
commit 5fcbc7e