-
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: fetch-depth: 1
and not cloning tags are dangerous defaults
#217
Comments
The default is
The behavior is prominent in the readme. And scenario guidance in the readme, for fetching more history and tags. I wonder whether there is something more in the log that should be printed. If downstream tools require more history, would it make sense for the tools to detect whether operating on a shallow repository? That is, whether |
fetch-depth: 0
and not cloning tags are dangerous defaultsfetch-depth: 1
and not cloning tags are dangerous defaults
Hey there,
Whoops, fixed the title.
Yep, I understand the trade-offs. I guess my problem here was that I wasn't aware of the default.
Yep - the README's great! The problem was that I never went through it in the first place (which is my own fault), not realizing that such issues could come up. This does signal quite a bit about the
Yeah this might be useful, but I'm not sure if this would've helped in this case, because everything seems to work fine and no errors come up. Checking the logs, and specifically the step that github actions are responsible for - pretty unlikely, just like in my case. Thank you for your responses - let's figure this out! |
I'm going to add a troubleshooting doc (for other issues). I wonder if it would make sense to add a section related to this issue. Unfortunate since as you mentioned, there is no error message :) |
Simpler config might also help, e.g.: ...
with:
all_commits: true
all_tags: true |
The "Fetch all tags" command in the readme doesn't always work as intended when it's used for being able to run The issue is that the initial fetch-depth of this action - if a value greater than 1 is set - doesn't necessarily fetch the correct commits to reach the desired tag(s). Running the custom fetch-all-tags command afterwards with a fetch depth value of just 1 may get all the individual tagged commits, but git won't always be able to trace the commit history back to the "nearest" tag when running See my comment with a more detailed description here, where we've just run into this issue: |
I understand the defaults being optimized for speed and efficiency. But it seems absolutely ridiculous that I need to do a completely separate step / command to get tags for the repository. You allow me to set fetch depth, but then you still add |
Seems pretty logical and reasonable to me that if I set |
I like the |
But it would not be slow by default. In my experience with large repos it is extremely fast even with a full clone. Apparently Github has a good connection to Github. I suspect this saves about 1-2 seconds on average for checkout time, and for us at least have wasted minutes-to-hours of developer time, multiply that out a bit and it looks like a poor trade-off (ane one none of the other CI providers seem to have made...). A very large proportion of CI workflows will want to know about tags.
Indeed
I think it would make more sense for Github Actions to change rather than everything else that already exists. This seems like a bad default. |
GH actions/checkout does a shallow clone (depth 1) by Unfortunately, this breaks Lerna's versioning tools. See actions/checkout#217
fyi - i updated v2 so that |
I also updated the README to make the default behavior more prominent |
Let me know if it's useful to keep this issue open any longer. Otherwise I'm planning to close. |
@ericsciple Is this still the most efficient way to pull 1 commit and all the tags? - use: actions/checkout@v2
- run: git fetch --depth=1 origin +refs/tags/*:refs/tags/* Like OP, I just need the latest tag to verify whether HEAD has been tagged. |
@fregante yes that looks correct to me |
Thanks all for the discussion. Sounds like this issue can be closed now. Reopen or open a new issue if any further changes required. Thanks! |
Otherwise, actions/checkout@v2 will only fetch the latest commit, leaving `git describe` unable to produce a useful version, cf. actions/checkout#100 and actions/checkout#217
Otherwise, `actions/checkout@v2` will only fetch the latest commit, leaving `git describe` unable to produce a useful version, cf. actions/checkout#100 and actions/checkout#217 Also switch to `actions/checkout@v2` when building the master branch and release Docker images.
Otherwise, `actions/checkout@v2` will only fetch the latest commit, leaving `git describe` unable to produce a useful version, cf. actions/checkout#100 and actions/checkout#217 Also switch to `actions/checkout@v2` when building the master branch and release Docker images.
Otherwise, `actions/checkout@v2` will only fetch the latest commit, leaving `git describe` unable to produce a useful version, cf. actions/checkout#100 and actions/checkout#217 Also switch to `actions/checkout@v2` when building the master branch and release Docker images.
Otherwise, `actions/checkout@v2` will only fetch the latest commit, leaving `git describe` unable to produce a useful version, cf. actions/checkout#100 and actions/checkout#217 Also switch to `actions/checkout@v2` when building the master branch and release Docker images.
We're using PBR, so let's make sure we don't get a package that's marked as version 0.0.0. Bug: actions/checkout#217 Change-Id: Icd8264a798f9a1a404e21a9b64317c57662d53fe
We're using PBR, so let's make sure we don't get a package that's marked as version 0.0.0. Bug: actions/checkout#217 Change-Id: Icd8264a798f9a1a404e21a9b64317c57662d53fe
We're using PBR, so let's make sure we don't get a package that's marked as version 0.0.0. Bug: actions/checkout#217 Change-Id: Icd8264a798f9a1a404e21a9b64317c57662d53fe
For those who mindlessly pasted the author's fix (like me) and are struggling with why most times steps:
- uses: actions/checkout@v2
+ with:
+ # pulls all commits (needed for lerna / semantic release to correctly version)
+ fetch-depth: "0"
- # pulls all tags (needed for lerna / semantic release to correctly version)
- - run: git fetch --depth=1 origin +refs/tags/*:refs/tags/*
|
…ding to the checked-out ref By default and for performance reasons, GitHub actions/checkout@v2 intentionally performs a zero-depth clone of the commit ref provided to it. For our use case, we would also like to have the git tag corresponding to the release available in the local repository clone so that poetry-dynamic-versioning can discover and use this tag name to determine the version label for the package build. A command to achieve this was discovered at actions/checkout#217 (comment) (and modified slightly to only fetch the relevant tag)
Thank you, @builtinnya! I kind of expected this, so I scrolled all the way down; it was worth it. |
I've had huge problems with github actions, specifically because of this action -
@actions/checkout
, and the defaults it has.Lerna (semantic release under the hood) will create an incorrect version bump when used inside github actions.
This happens because by default, the https://github.com/actions/checkout will only fetch the git repository with
--depth=1
and will not fetch the tags.In order to fix this, you need to make the following changes to your workflow:
Cheers! Hopefully I'll save someone else's time, because for me this has been a real struggle for a while.
I've already created FYIs in lerna/lerna#2542 and semantic-release/semantic-release#1526, since these are the tools I've used when I encountered the issue, but I'd also like to discuss it here.
I've previously used CircleCI and that was never an issue, but ever since I've switched to github actions, this has been secretly hiding & I didn't even notice that there were incorrect version bumps produced - I'm bringing attention to this to hopefully save some time for others, or just get the issue fixed in the first place:D
The fix I found was from here: https://stackoverflow.com/questions/60180630/lerna-always-lists-all-packages-ready-to-publish-when-running-workflow-of-github
and the funny thing is how I found it:
I've noticed that
lerna
runs & versions incorrectly in my github actions workflow, but once runninglerna version
locally, everything works fine.I've checked the outputs of lerna locally and in the CI, and there was a slight difference (red - inside github actions - bad; green - locally - good):
notice the first 3 lines:
so I just googled "lerna Assuming all packages changed" and ended up at this stack overflow thread:
https://stackoverflow.com/questions/60180630/lerna-always-lists-all-packages-ready-to-publish-when-running-workflow-of-github
and the author himself found the solution! As explained above, it's because github's
@actions/checkout
does not fetch all commits & tags!The text was updated successfully, but these errors were encountered: