Skip to content
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

checkout@v2 not getting recent commits #439

Open
adnan-kamili opened this issue Feb 9, 2021 · 26 comments
Open

checkout@v2 not getting recent commits #439

adnan-kamili opened this issue Feb 9, 2021 · 26 comments

Comments

@adnan-kamili
Copy link

Assume a Github action with two Jobs - job1 & job2

In job1:
Use checkout action to checkout the repo, update any file in the repo, commit and push the changes.

In job2:

Again use checkout action. The repo doesn't contain the commit made in job1.

Here is a replicable sample:

jobs:
  update-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: |  
          // update file1.txt
          git add file1.txt
          git config --local user.email "github-actions@users.noreply.github.com"
          git config --local user.name "github-actions"
          git commit -m "updated file1"
          git push
        
  deploy:
    needs: update-version
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: cat publish file
      run: |
        # the changes made in job1 are not reflected here
         cat file1.txt
@jcharnley
Copy link

what error code is it giving you, something has changed with my pipeline and not sure what the issue is

@adnan-kamili
Copy link
Author

I don't get any error, the checkout succeeds but it doesn't get the latest commits. Seems to use some sort of cache. As a workaround I am doing the following:

  • uses: actions/checkout@v2
  • run: git pull origin master

@vmehra-pcln
Copy link

vmehra-pcln commented Feb 27, 2021

I ran into the same issue. I have 2 jobs:
Job-1: actions/checkout@v2, modify a file, commit the file, push the file

Job2: actions/checkout@v2

It doesn't error out but it does log below which shows the last commit pushed within Job-1 is not there.

Checking out the ref
  /bin/git checkout --progress --force -B project-name refs/remotes/origin/project-name
  Warning: you are leaving 1 commit behind, not connected to
  any of your branches:

As a workaround, I had to do - run: git pull --no-rebase with Job-2 checkout (similar to what @adnan-kamili mentioned above)

@punksta
Copy link

punksta commented Mar 15, 2021

Same here

git checkout --progress --force 29289099907df8d8600cf5c8f58bab9a15dcaac8
Error: fatal: reference is not a tree: 29289099907df8d8600cf5c8f58bab9a15dcaac8
Error: Git checkout failed with exit code: 128
Error: Exit code 1 returned from process: file name '/home/runner/runners/2.277.1/bin/Runner.PluginHost', arguments 'action "GitHub.Runner.Plugins.Repository.v1_0.CheckoutTask, Runner.Plugins"'.

@jcharnley
Copy link

changed ubuntu-latest to a acutal version

twje added a commit to 2pisoftware/cmfive-core that referenced this issue Mar 16, 2021
@sebastian-muthwill
Copy link

I ran into the same problem and came across this issue. But could figure out a solution within the documentation.

# The branch, tag or SHA to checkout. When checking out the repository that

    # triggered a workflow, this defaults to the reference or SHA for that event.
    # Otherwise, uses the default branch.
    ref: ''

This means by default the commit where the workflow was triggered will be taken. You can specify the master branch with
ref: 'master'

@brianpham
Copy link

brianpham commented Jul 22, 2021

Running into the same issue. We should be able to do a checkout again without needing to specific the ref in dispatch workflow.

Dispatch Workflow starts off with checking out branch (2)

  1. Checkout branch (1)
  2. Create new branch (2) off branch (1)
  3. Force push branch (2)
  4. Checkout branch (2)

Step 4 seems to be pulling an old branch git sha.

Maybe this is normal behavior? According to this https://docs.github.com/en/actions/reference/events-that-trigger-workflows#manual-events

If I check out branch (2) it will use the last github_ref. So even if I update the branch (2) and run step 4, it will still pull the older branch. Can someone help confirm?

@mugbug
Copy link

mugbug commented Aug 12, 2021

I had a similar issue while trying to use standard-version to generate the changelog with previous commits. The problem was that it wasn't fetching the commit history and only the last commit was available. I was able to solve this by running this command, which forces the commit history to be fetched:

git fetch --prune --unshallow

@restfulhead
Copy link

As @sebastian-muthwill mentions, you can use the ref attribute to point to a specific branch. This way subsequent jobs always pull the latest code from that branch, and not from the revision that started the workflow.

@mugbug I think fetch-depth: 0 is your friend.

Here's a full example that works for me when running multiple jobs that each generate a change-log file (i.e. modify the branch)

    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
          ref: main

@adnan-kamili Does this solve your issue?

@Farrukhbek00
Copy link

In my case, S3 bucket on AWS was cached and was updating cached files in folder, I deleted project folder on aws s3, and ran github action again, hope it helps

@rockymountainhigh1943
Copy link

The solution from @restfulhead fixed my issues. It was the missing ref: main.

valentinkoe pushed a commit to secvisogram/csaf-cms-backend that referenced this issue May 2, 2022
…e intermediate commits are included

without defining branch, the second checkout would skip previous automatic commits
see actions/checkout#439
valentinkoe pushed a commit to secvisogram/csaf-cms-backend that referenced this issue May 2, 2022
…e intermediate commits are included

without defining branch, the second checkout would skip previous automatic commits
see actions/checkout#439
iqfareez added a commit to iqfareez/astros-api that referenced this issue May 17, 2022
that was related to this issue actions/checkout#439
marcolovazzano added a commit to marcolovazzano/semantic-release that referenced this issue Jun 30, 2022
punchagan added a commit to punchagan/sandmark-nightly that referenced this issue Jul 27, 2022
Fetching with the default fetch-depth of 1 led to a strange bug where the
commit fetched would be different from the one that triggered the build, unless
the build was triggered manually. It is not entirely clear why this happens,
and debugging with using things like `git rev-parse HEAD` etc didn't give any
hints. The issue [here](actions/checkout#439) seems
to be the problem, and this commit addresses it by setting fetch-depth to 0.
punchagan added a commit to punchagan/sandmark-nightly that referenced this issue Jul 27, 2022
Fetching with the default fetch-depth of 1 led to a strange bug where the
commit fetched would be different from the one that triggered the build, unless
the build was triggered manually. It is not entirely clear why this happens,
and debugging with using things like `git rev-parse HEAD` etc didn't give any
hints. The issue [here](actions/checkout#439) seems
to be the problem, and this commit addresses it by setting fetch-depth to 0.
punchagan added a commit to punchagan/sandmark-nightly that referenced this issue Jul 27, 2022
Fetching with the default fetch-depth of 1 led to a strange bug where the
commit fetched would be different from the one that triggered the build, unless
the build was triggered manually. It is not entirely clear why this happens,
and debugging with using things like `git rev-parse HEAD` etc didn't give any
hints. The issue [here](actions/checkout#439) seems
to be the problem, and this commit addresses it by setting fetch-depth to 0.
punchagan added a commit to punchagan/sandmark-nightly that referenced this issue Jul 27, 2022
Fetching with the default fetch-depth of 1 led to a strange bug where the
commit fetched would be different from the one that triggered the build, unless
the build was triggered manually. It is not entirely clear why this happens,
and debugging with using things like `git rev-parse HEAD` etc didn't give any
hints. The issue [here](actions/checkout#439) seems
to be the problem, and this commit addresses it by setting fetch-depth to 0.
@LastDragon-ru
Copy link

LastDragon-ru commented Aug 6, 2022

ref doesn't work for me :(

image

image

andgein added a commit to HITB-CyberWeek/hitbsecconf-ctf-2022 that referenced this issue Aug 23, 2022
seanbudd added a commit to nvaccess/addon-datastore that referenced this issue Mar 27, 2023
Should close #219
actions/checkout#439 (comment) encourages setting the ref explicitly to always pull the latest data from the ref.
When performing the transformation to views, we always want to use master data, so it is safer to set the ref unambiguously, instead of using the inherited reference (which may come from a different branch/commit).
@schnerring
Copy link

schnerring commented Apr 2, 2023

IMO the best™ approach is the following:

jobs:
  update-changelog:
    runs-on: ubuntu-latest
    outputs:
      commit_hash: ${{ steps.commit-and-push.outputs.commit_hash }}
    steps:
      - name: Check Out the Repo
        uses: actions/checkout@v3

      - name: Update CHANGELOG.md
        run: echo "Added changes on $(date)" >> CHANGELOG.md

      - name: Commit and Push Changes
        id: commit-and-push
        uses: stefanzweifel/git-auto-commit-action@v4

#      Or do things manually instead of using git-auto-commit-action
#      - name: Commit and Push Changes
#        id: commit-and-push
#        run: |
#          git add CHANGELOG.md
#          git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
#          git config --local user.name "github-actions[bot]"
#          git commit -m "Update changelog"
#          git push
#          echo "commit_hash=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

  publish:
    needs: update-changelog
    runs-on: ubuntu-latest
    steps:
      - name: Check Out the Repo Again
        uses: actions/checkout@v3
        with:
          ref: ${{ needs.update-changelog.outputs.commit_hash }}

      - name: Display CHANGELOG.md
        run: |
          cat CHANGELOG.md
          # The changes are here 🎉🎉🎉

By passing the commit hash of the pushed commit from the first job update-changelog to the second job publish, we ensure that we check out exactly what we pushed before and not something that might have been pushed in between the job runs.


This isn't really an issue, but a topic surrounded by a bit of confusion in regards to how the action works. When we talk about push events to branches, by default, the action ensures that it exactly checks out the commit specified in the github.sha variable of the github context. Because the value of github.sha doesn't change over the lifetime of a workflow run, the action checks out the same commit across all jobs, whether you push something or not.

By setting the ref parameter to main or ${{ github.ref }}, the behavior of the action changes and it will instead always pull the latest commit available. Running git pull has effectively the same result. This will work fine in the majority of cases, but race conditions may occur:

image

For anyone interested, you can read more about this topic on my blog (shameless plug).


The one thing I'm still curious about is people reporting different results between operating systems. I've had a bit of fun analyzing this, so I created a repository that runs daily tests with the following scenarios:

  1. default checkout
  2. default checkout + git pull
  3. checkout with ref: ${{ github.ref }}
  4. "checkout exact": the method I explained above

I run these tests on all the runner images available (ubuntu-22.04, ubuntu-20.04, macos-12, macos-11, windows-2022, windows-2019), but so far the everything returns the expected results. 🤷 I thought that these discrepancies might stem from the different Git implementations used within the runner images. I'll keep an eye on the results, maybe something turns up in the future.

For anyone interested, I use Hugo to automatically publish the results here: https://commit-and-checkout-actions-workflow.schnerring.net/. Turning this into unit tests would also be pretty straightforward.

jgarber623 added a commit to jgarber623/nasa-apod that referenced this issue May 27, 2023
So… when the scrape workflow triggers the build workflow, the build
workflow doesn't check out the latest commit. This appears to be an
issue because it inherits the SHA from the calling workflow.

Since the scrape workflow creates a new comimt, the existing ref is the
next-to-last commit. Some folks figured out a workaround:

actions/checkout#439 (comment)
@RaulTrombin
Copy link

RaulTrombin commented Aug 8, 2023

many thanks schnerring, using this method based on GITHUB_OUTPUT it worked beetwen different jobs, thkns!
None of the other methods worked, maybe because I'm triggering by a tag? Then apparently you can't git pull or get latest commits.
PR that uses this concept - based on commit hash shared beetwen jobs

hathagat added a commit to hathagat/nginx that referenced this issue Aug 30, 2023
hmenager added a commit to research-software-ecosystem/content that referenced this issue Oct 9, 2023
always checkout latest version of the data repo
see https://github.com/actions/checkout and actions/checkout#439
hmenager added a commit to research-software-ecosystem/content that referenced this issue Nov 1, 2023
solve the issue of successive import tasks in the repo not working because the latest repo commit is not checked out by the next task. As described in actions/checkout#439, applying solution described in actions/checkout#439 (comment)
@luqmanrom
Copy link

From the docs:

Only a single commit is fetched by default, for the ref/SHA that triggered the workflow. Set fetch-depth: 0 to fetch all history for all branches and tags

@eliduke
Copy link

eliduke commented Mar 6, 2024

I was having this same issue with checkout@v4, thought I was taking wacky pills, so I am very thankful for this thread! It feels great knowing that I am not alone in this issue.

In the end, the fetch-depth option wasn't necessary, but adding the ref: main to my checkout step did the trick.

So, for any of you checkout@v4 folks this is what worked for me:

- name: Checkout
  uses: actions/checkout@v4
  with:
    ref: main

corentin-regent added a commit to corentin-regent/rate-control that referenced this issue Mar 24, 2024
corentin-regent added a commit to corentin-regent/rate-control that referenced this issue Mar 26, 2024
@Kaloszer
Copy link

Kaloszer commented Apr 4, 2024

What the hell, I was thinking I was popping crazy pills, how is this even an issue.

Serene-Arc added a commit to Serene-Arc/beets that referenced this issue Jun 1, 2024
Looking at the logs, it's using the ref before the one that increments
the version in the previous action in the workflow. This code is from
actions/checkout#439 (comment)
and supposedly fixes this by making it pull specifically from master,
rather than the ref that the workflow was called on.
Serene-Arc added a commit to Serene-Arc/beets that referenced this issue Jun 2, 2024
Looking at the logs, it's using the ref before the one that increments
the version in the previous action in the workflow. This code is from
actions/checkout#439 (comment)
and supposedly fixes this by making it pull specifically from master,
rather than the ref that the workflow was called on.
snejus pushed a commit to Serene-Arc/beets that referenced this issue Jun 5, 2024
Looking at the logs, it's using the ref before the one that increments
the version in the previous action in the workflow. This code is from
actions/checkout#439 (comment)
and supposedly fixes this by making it pull specifically from master,
rather than the ref that the workflow was called on.
@rrrodzilla
Copy link

Thanks folks. This saved me a ton of headache.

facebook-github-bot pushed a commit to WhatsApp/erlang-language-platform that referenced this issue Jul 29, 2024
Summary: Apparently needed even in `checkout@v3/v4` to include all commits without delay according to actions/checkout#439.

Reviewed By: alanz

Differential Revision: D60391729

fbshipit-source-id: 4c0a8c4073f4a3c7842b9bc8aa24ed00d1a462ac
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests