You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
0 commit comments