Solvedcheckout RFC: fetch-depth: 1 and not cloning tags are dangerous defaults

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:

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/*

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 running lerna 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):

4c4
4c4
< lerna info Assuming all packages changed
---
> lerna info Looking for changed packages since v2.1.5
8,12c8,11
<  - @turbo-schedule/client: 2.1.5 => 2.1.6
<  - @turbo-schedule/common: 2.1.5 => 2.1.6
<  - @turbo-schedule/database: 2.1.5 => 2.1.6
<  - @turbo-schedule/scraper: 2.1.5 => 2.1.6
<  - @turbo-schedule/server: 2.1.5 => 2.1.6
---
>  - @turbo-schedule/common: 2.1.5 => 2.2.0
>  - @turbo-schedule/database: 2.1.5 => 2.2.0
>  - @turbo-schedule/scraper: 2.1.5 => 2.2.0
>  - @turbo-schedule/server: 2.1.5 => 2.2.0

notice the first 3 lines:

< lerna info Assuming all packages changed
---
> lerna info Looking for changed packages since v2.1.5

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!

17 Answers

✔️Accepted Answer

Simpler config might also help, e.g.:

  ...
  with:
    all_commits: true
    all_tags: true

Other Answers:

fyi - i updated v2 so that fetch-depth: 0 now fetches all tags and branches

The default is depth: 1, not depth: 0.

checkout@v2 fetches only a single commit by default. It's an intentional perf optimization for the mainline scenario (just need the files). Slow by default has different problems, users would need to opt-in to perf.

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 .git/shallow file exists. It however doesn't solve the problem where tags haven't been fetched. By default the GITHUB_TOKEN is persisted in the git config, so if tags are required, downstream tool could run git fetch.

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 --no-tags so I still gotta do a separate command.

I like the fetch-depth: 0 suggestion quite a bit. It's simple.