Skip to content

The binaries built by the release action include the commit hash in their version #38

Closed
@ejpcmac

Description

@ejpcmac

Problem description

If I run a binary downloaded from the release page and print its short version, I get the following:

$ ./git-z-0.2.1-x86_64-unknown-linux-musl -V
git-z 0.2.1+e0e62f1

Expected behaviour

In releases, the short version should not contain the Git revision.

Analysis

In the different build jobs of the release action, the Git repository is cloned using actions/checkout@v4 without any parameter. By default, this only does a shallow clone, which does not include tags. Hence, the build.rs is not able to check whether the build is made from a tag matching the version, and the revision is then included.

Solution

Set fetch-tags: true in the parameters for actions/checkout@v4 for the build-bin, build-deb and build-msi jobs.

^ This solution makes the fetch fail. Replacing it with fetch-depth: 0 makes the build work again, but… does still include the hash.

Second round of analysis

When fetching the repository with fetch-depth: 0 on a tag, the action does the following:

  /usr/bin/git -c protocol.version=2 fetch --prune --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
  From https://github.com/ejpcmac/git-z
   * [new branch]      develop    -> origin/develop
   * [new branch]      main       -> origin/main
   * [new tag]         v0.1.0     -> v0.1.0
   * [new tag]         v0.2.0     -> v0.2.0
   * [new tag]         v0.2.1     -> v0.2.1
   * [new tag]         v0.2.2     -> v0.2.2
  /usr/bin/git tag --list v0.2.2
  v0.2.2
  /usr/bin/git rev-parse refs/tags/v0.2.2
  2efee1538e1e9a6d61c458b2a1242c32e09f4651
  /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules origin +45b8aee6cc9d596ce882ee66dd26106e469e1e08:refs/tags/v0.2.2
  From https://github.com/ejpcmac/git-z
   t [tag update]      45b8aee6cc9d596ce882ee66dd26106e469e1e08 -> v0.2.2

Is is then updating the tag so it directly points to the commit, instead of being an annotated tag. This only occurs if the action is triggered on a tag.

I have reproduced the last command locally, and then ran git describe. I am getting the following:

v0.2.1-34-g45b8aee

Thanks to this comment, I have discovered that we can do git describe --tags:

v0.2.2

Second solution

Updating the build.rs to run git describe --tags instead of git describe should fix the issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Status

    Solved

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions