-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] providing git-describe alike metadata in a env var #249
Comments
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 |
@RonnyPfannschmidt fyi - i just pushed an update to fetch all branches/tags when fetch-depth=0 |
@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? |
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 |
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 |
@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 |
@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 |
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.
The text was updated successfully, but these errors were encountered: