Wrong reported version, while running under actions/checkout@v2

[skirpichev]

E.g. in this build I got "0.1.dev1+g731594d", while correct one is something like "0.11.0a15.dev184+g5cbde2799".

[RonnyPfannschmidt]

Off hand the reason is not clear, can you add a SETUPTOOLS_SCM_DEBUG=1 setup.py --version call to get extra information

[skirpichev]

See this build, linting step:

root '/home/runner/work/diofant/diofant'
looking for ep setuptools_scm.parse_scm /home/runner/work/diofant/diofant
found ep .git = setuptools_scm.git:parse
cmd 'git rev-parse --show-toplevel'
out b'/home/runner/work/diofant/diofant\n'
real root /home/runner/work/diofant/diofant
cmd 'git describe --dirty --tags --long --match *.*'
err b'fatal: No names found, cannot describe anything.\n'
ret 128
cmd 'git rev-parse --verify --quiet HEAD'
out b'767e300ac7b6f31ad456073028782874b4d5c101\n'
cmd 'git status --porcelain --untracked-files=no'
cmd 'git rev-list HEAD'
out b'767e300ac7b6f31ad456073028782874b4d5c101\n'
cmd 'git rev-parse --abbrev-ref HEAD'
out b'HEAD\n'
tag 0.0
tag '0.0' parsed to {'version': '0.0', 'prefix': '', 'suffix': ''}
version pre parse 0.0
version <Version('0.0')>
version 0.0 -> 0.0
scm version <ScmVersion 0.0 d=1 n=g767e300 d=False b=HEAD>
config {'version_scheme': 'guess-next-dev', 'local_scheme': 'node-and-date'}
ep ('setuptools_scm.version_scheme', 'guess-next-dev')
ep found: guess-next-dev
ep ('setuptools_scm.local_scheme', 'node-and-date')
ep found: node-and-date
version 0.1.dev1
local_version +g767e300
/home/runner/work/diofant/diofant/.eggs/setuptools_scm-3.5.0-py3.7.egg/setuptools_scm/git.py:68: UserWarning: "/home/runner/work/diofant/diofant" is shallow and may cause errors
0.1.dev1+g767e300
  warnings.warn('"{}" is shallow and may cause errors'.format(wd.path))

[RonnyPfannschmidt]

It seems the clone depth is zero and no tags get loaded, which in turn takes away all of the Metadata setuprools_scm needs, please use a full clone

[skirpichev]

Oh, I see. Probably, this recipe will work. But I would prefer to wait for a better solution, perhaps that PR. v1 version is working again, anyway...

Thank you for help. Feel free to close this bugreport or document this somewhere somehow...

[RonnyPfannschmidt]

for setuptools_scm 4.0 i will cause an error here

[chrisjbillington]

Fetching all tagged commits doesn't solve the issue - git can't count the number of intervening commits, or even know which of the tagged commits is the closest parent to master. You need every commit in between.

Be nice if there was a kind of shallow clone where all commit objects from deeper than --depth were pulled in, and just not the tree objects they reference.

[webknjaz]

@chrisjbillington here's a working example of how to do it in GHA: https://github.com/ansible/pylibssh/blob/1e7b17f/.github/workflows/build-test-n-publish.yml#L146-L151

(credit: @matthewfeickert)

[RonnyPfannschmidt]

im closing this one as current suggestion is to fetch everything

#431 is a followup to make better workflows

[steven-murray]

I'm having a problem with this -- I think it is related, but I guess maybe I'm missing something else.

Here's my workflow: https://github.com/steven-murray/hmf/pull/62/checks?check_run_id=694283873

Short problem: I am using

        run: |
          git fetch --prune --unshallow
          git fetch --depth=1 origin +refs/tags/*:refs/tags/*
          git describe --tags
          git describe --tags $(git rev-list --tags --max-count=1)

as described in the link posted above. The last two lines are printing

v3.0.9-8-g97882b1
v3.0.9

which is what I would expect.

However, I have a step after this that does

python -m pip install setuptools>=42 wheel setuptools_scm --user
python setup.py --version

to print out the version that setuptools_scm should be giving (should be 3.0.9.something). Instead, it's printing out 0.0.0 every time.

My full workflow is here: https://github.com/steven-murray/hmf/blob/pypi/.github/workflows/publish-to-pypi.yaml

Any help would be much appreciated!

[webknjaz]

@steven-murray it's unrelated. You use a legacy setup.py invocation but forgot to configure it: https://github.com/pypa/setuptools_scm#setuppy-usage.

[steven-murray]

@webknjaz thank you, that did it. I didn't realize that merely having a setup.py would cause it to break. I now have both the pyproject.toml and entry in setup() and it's working. Thanks again!

[webknjaz]

@steven-murray I think it wasn't about having setup.py but about invoking it directly.

[webknjaz]

FTR I've faced another interesting incarnation of this.
I use:

          git fetch --prune --unshallow
          git fetch --depth=1 origin +refs/tags/*:refs/tags/*

followed by removing the tags from HEAD for pushes to devel (it's my solution to a certain race condition).
And this works under Ubuntu. But in macOS builders, Git doesn't seem to be able to detect the previous tag and falls back to v0.1 too. (Even though the previous tag is just one commit back, as in depth=1)

Just wanted to document this corner case.
Refs:

• https://github.com/ansible/pylibssh/runs/808731176?check_suite_focus=true#step:15:63 (macOS, broken version)
• https://github.com/ansible/pylibssh/runs/808731287?check_suite_focus=true#step:9:4303 (GNU/Linux, correct version)

[RonnyPfannschmidt]

@webknjaz please open a new issue and consider rerunning with debug

[webknjaz]

I don't think this is necessary. It's probably not this project's fault. I only wanted to document this so that it'd be useful to folks coming to this page from Google.