git fetch on tag builds does not fetch the tag that initiated the build

I’m seeing some really weird behavior when subscribing to the push: tags event:

on:
  push:
    tags:
      - '*'

When a build is initiated from the creation of tag, a step doing git fetch --prune --unshallow --tags does not fetch the tag that initiated the build. This build was initiated from creating tag 1.0.3 as can be seen by the refs/tags/1.0.3 value of github.ref. But as the output from git fetch shows, tag 1.0.3 isn’t fetched:

From https://github.com/SwedbankPay/kramdown-plantuml
* [new branch] develop -> origin/develop
* [new branch] master -> origin/master
* [new tag] 1.0.0 -> 1.0.0
* [new tag] 1.0.1 -> 1.0.1
* [new tag] 1.0.2 -> 1.0.2

Not having access to the tag makes GitVersion not work properly, generating the version number 1.1.0-tags-1-0-3.1+15 instead of 1.0.3.

Can someone please explain why the tag that initiated the build is not available to the build itself?

PS: I sincerely hate the forum software you’ve chosen here and the fact that something so specifically targeted at developers makes it impossible to use Markdown or HTML to format messages. I enjoy writing GitHub issues 178 times more than writing into this godforsaken “rich text” field. Please, burn this to the ground. Thank you.

Hi @asbjornu,

The default fetch depth is ‘1’ for action ‘actions/checkout@v2’, it will checkout the latest tag(1.0.3). Hence, when you run command ‘git fetch --prune --unshallow --tags’, it’ll get the non-existing tags which ends with tag ‘1.0.2’.  I confirmed the appearance is same on my local git env.

For GitVersion use, please check ticket: https://github.community/t5/GitHub-Actions/Checkout-Action-does-not-create-local-master-and-has-no-options/m-p/31575

Hope it helps!

Thanks for the information, @weide-zhou. I was not aware of fetch-depth: 0. However, setting that now leads to GitHub Actions not being triggered at all, for whatever reason. A temporary glitch in the matrix? Also, from the issue you linked, it seems that it should be fixed in v2 of the checkout action:

…there will be a 2.0 version coming that will make sure you are not in a detached head state.

What I don’t understand, still, is how git fetch on the same repository that the tag 1.0.3 was pushed to, for builds triggered by the creation of 1.0.3, can’t fetch tag 1.0.3.

I ended up just using the git tag directly and disable GitVersion when the build is triggered from a tag with if: startsWith(github.ref, ‘refs/tags/’) != true. I perform the stable/unstable versioning logic with actions/github-script as follows:

const gemVersion = (function() {
  const ref = '${{ github.ref }}';
  const tagPrefix = 'refs/tags/';

  if (ref.startsWith(tagPrefix)) {
    // If a tag ref is being built, just return the tag verbatim
    return ref.substring(tagPrefix.length);
  }

  const escapedBranchName = '${{ steps.gitversion.outputs.escapedBranchName }}';
  const commitsSinceVersionSource = '${{ steps.gitversion.outputs.commitsSinceVersionSourcePadded }}';
  const preReleaseLabel = escapedBranchName + '.' + commitsSinceVersionSource;
  const majorMinorPatch = '${{ steps.gitversion.outputs.majorMinorPatch }}';
  return majorMinorPatch + preReleaseLabel;
})();

core.setOutput('version', gemVersion);

It would be much easier if I could just do git fetch --tags in the build to have the tag being built locally, but as that seems impossible, this is at least a suitable workaround.