During checkout, retrieve all commits and tags

[hoechenberger]

No description provided.

[hoechenberger]

cc @cbrnr @larsoner

I saw in other PRs:

2024-04-13T18:15:26.9073758Z * Creating isolated environment: venv+pip...
2024-04-13T18:15:26.9607420Z * Installing packages in isolated environment:
2024-04-13T18:15:28.7808422Z   - hatch-vcs
2024-04-13T18:15:28.7809025Z   - hatchling
2024-04-13T18:15:28.7810899Z * Getting build dependencies for sdist...
2024-04-13T18:15:28.8864272Z * Building sdist...
2024-04-13T18:15:29.2047469Z /tmp/build-env-xwqvbncu/lib/python3.10/site-packages/setuptools_scm/git.py:163: UserWarning: "/home/runner/work/openneuro-py/openneuro-py" is shallow and may cause errors
2024-04-13T18:15:29.2048664Z   warnings.warn(f'"{wd.path}" is shallow and may cause errors')
2024-04-13T18:15:29.3109724Z Successfully built openneuro_py-0.1.0.dev1+g392b40c.tar.gz

So the version number is wrong and we get a warning … I hope that fetching the entire git history (as per this PR) will fix this problem.

AFAIK it never affected our build+publish workflow as this one is only triggered on release, and then the GH checkout action retrieves the entire git history by default already

Edit:

Yep, seems to work:

2024-04-13T18:22:34.6097456Z * Creating isolated environment: venv+pip...
2024-04-13T18:22:34.6164282Z * Installing packages in isolated environment:
2024-04-13T18:22:36.6284100Z   - hatch-vcs
2024-04-13T18:22:36.6284694Z   - hatchling
2024-04-13T18:22:36.6285181Z * Getting build dependencies for sdist...
2024-04-13T18:22:36.7390133Z * Building sdist...
2024-04-13T18:22:37.1543894Z Successfully built openneuro_py-2024.3.0.dev10+g03b51e1.tar.gz

[cbrnr]

So it seems this warning/error is due to raw-options = { version_scheme = "release-branch-semver" }, right? Whatever the default is, it should work even with a checkout depth of 1 (i.e. just 1 commit). (Not asking to switch, but because I'm trying to understand what's going on.)

[hoechenberger]

I don't think that's the full explanation, as the checkout action also doesn't seem to retrieve all tags by default

So determining the version number just on the very last commit and tag won't work either

Maybe the last tag will be received if it corresponds to the latest commit, I haven't tried that

We could copy the checkout action's command line and play with it to find out the required options. But I currently don't have time for this

[hoechenberger]

It appears this problem is also being tracked upstream at actions/checkout#249

[hoechenberger]

The checkout action also has a fetch-tags setting, which if true will fetch the tags even when fetch-depth is not zero. This could be an acceptable workaround for CI testing to avoid having to retrieve the entire repository with all commits

Not sure if it will get rid of the "shallow repository" warning though.

[cbrnr]

AFAIK it never affected our build+publish workflow as this one is only triggered on release, and then the GH checkout action retrieves the entire git history by default already

I don't understand why and how this happens; the checkout action is identical to the one in the tests, or no? https://github.com/hoechenberger/openneuro-py/blob/main/.github/workflows/python-publish.yml#L31

[hoechenberger]

I don't understand why and how this happens; the checkout action is identical to the one in the tests, or no?

Yes but the action itself parses what event triggered the action (new tag, release, commit, …) and adjusts its behavior accordingly.

[cbrnr]

Where did you find that information? I can't find it in their docs...

[hoechenberger]

Where did you find that information? I can't find it in their docs...

I thought I saw this in their code somewhere, but I'm failing to discover it again :D So … maybe I was mistaken!

Maybe because the Publish workflow only runs once we've added a tag, retrieving the latest commit will also load the tag that points to this commit, and everything works as intended then? And it's just a happy coincidence for us.

Definitely worth investigating!

Maybe the safest approach for now really is setting the fetch-depth to 0 for all workflows!!

@cbrnr I'd appreciate it if you could find the time to dig a little bit into this – I'm rather busy this week :( Or maybe @larsoner can help! In any case, we should try to better understand what's going on to ensure we won't run into unintended problems in the future!

also tagging @sappelhoff, @drammock and @agramfort just to keep them in the loop.