checkout
checkout copied to clipboard
checkout@v2 not getting recent commits
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 "[email protected]"
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
what error code is it giving you, something has changed with my pipeline and not sure what the issue is
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
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)
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"'.
changed ubuntu-latest to a acutal version
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'
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)
- Checkout branch (1)
- Create new branch (2) off branch (1)
- Force push branch (2)
- 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?
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
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?
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
The solution from @restfulhead fixed my issues. It was the missing ref: main
.
ref
doesn't work for me :(
Got the same issue too. Steps as below:
- create new action workflow, we have .github/workflows/xxx.yml here.
- run workflow, and it's failed due to any wrong config within .github/workflows/xxx.yml
- delete workflow and remove .github/workflows/xxx.yml
- do the same with step 1 - 3, but fix the wrong config with the same file name .github/workflows/xxx.yml
- run worflow agin, it's failed again
During the error log, it's also take v1 version config file as reference and ignore the updated one
Having the same issue with actions/checkout@v3. The checkout function is pulling the most recent version of the repository for windows and macos, but not for ubuntu-latest.
It is pulling an older version of the repository for the ubuntu-latest runner and because of this my linux tests are failing. Tried many of the suggestions above, none have worked to fix this issue.
fetch-depth: 0
worked for me, ref:
is irrelevant in my case.
Having the same issue with actions/checkout@v3. The checkout function is pulling the most recent version of the repository for windows and macos, but not for ubuntu-latest.
It is pulling an older version of the repository for the ubuntu-latest runner and because of this my linux tests are failing. Tried many of the suggestions above, none have worked to fix this issue.
I can confirm its still the case. Guys tests on ether windows and mac to reproduce and test. Thanks
I confirm it is still there.
To add to @restfulhead's answer, fetch-depth: 0
is not necessary.
This example always checks out the latest commit of the branch that triggered the workflow.
- name: Checkout
uses: actions/checkout@v3
with:
ref: ${{ github.ref }}
To add to @restfulhead's answer,
fetch-depth: 0
is not necessary. This example always checks out the latest commit of the branch that triggered the workflow.- name: Checkout uses: actions/checkout@v3 with: ref: ${{ github.ref }}
Thanks, This worked for me!
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:
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:
- default checkout
- default checkout +
git pull
- checkout with
ref: ${{ github.ref }}
- "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.
I am currently running into this issue:
- https://github.com/gruvw/portfolio/blob/6b82fea7a5c5705e432982406fc5d189badd6809/.github/workflows/build-jekyll.yml#L49
- workflow: https://github.com/gruvw/portfolio/actions/runs/5046101941/jobs/9051182850#step:3:388
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
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
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
What the hell, I was thinking I was popping crazy pills, how is this even an issue.