[RFC] providing git-describe alike metadata in a env var

[RonnyPfannschmidt]

With tools that use scm metadata to guess the current/next version, the setup of fetching only one commit and no tags, basically implies that the tools have to fetch tags/commits in order to be able to provide metadata again

if the checkout action could provide that metadata in a env var by a opt/in/extra list of options, it could spare that expensive check.

[chrisjbillington]

Manually fetching tags is also racy. If you have a branch push before a tag creation, resulting in a workflow running twice, the former may or may not see the tag, depending on timing.

Any solution to this should avoid this race condition. I've been considering making my workflows fetch all tags, then unless the event is a tag creation event, deleting any tag on the current commit. (A subtlety: what if the tag was pushed before its branch? I wouldn't want to delete it then)

Edit: am currently using the following:

- uses: actions/checkout@v2
- if: github.event.ref_type != 'tag'
  run: |
    git fetch --prune --unshallow
    git tag -d $(git tag --points-at HEAD)

So if this workflow runs on both branch-push and tag-create, then the branch-push one is always processed without the tags on the current commit (but still with previous tags). This makes it deterministic what version setuptools_scm sees.

[ericsciple]

@RonnyPfannschmidt fyi - i just pushed an update to fetch all branches/tags when fetch-depth=0

[ericsciple]

@RonnyPfannschmidt can you help me understand the proposal better? In order for the expensive check to be avoided, doesn't some step (whether checkout or otherwise) have to perform the fetch?

Or is there a REST API or GraphQL query that can be used to retrieve the information?

[RonnyPfannschmidt]

The idea here is to help tools by providing data that would require subprocess calls and/or unshallow/tag fetching in a standardised env var.

I haven't yet investigated how to address that

[RonnyPfannschmidt]

since pypa/setuptools_scm#480 and the action turning in less metadata, this is becoming more and more of an issue as a build cant tell its actual metadata without incurring some extra cost

[webknjaz]

@RonnyPfannschmidt I've started building the dists in a dedicated job that runs before tests and unpacking those artifacts via https://github.com/re-actors/checkout-python-sdist. This way, there's only one job that has to deal with actions/checkout and depth: 0. I think this is acceptable to happen in just one single place. It also adds a benefit of testing from sdist and being downstream-friendly this way...

[RonnyPfannschmidt]

@webknjaz i also started to use hyneks bild and inspect workflow ehere i can, but i still would like to get git describe data in some way that inexpensive