-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Comments
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:
|
I ran into the same issue. I have 2 jobs: 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.
As a workaround, I had to do |
Same here
|
changed ubuntu-latest to a acutal version |
- actions/checkout#439 refs: 7851
I ran into the same problem and came across this issue. But could figure out a solution within the documentation.
This means by default the commit where the workflow was triggered will be taken. You can specify the master branch with |
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)
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
|
As @sebastian-muthwill mentions, you can use the @mugbug I think 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)
@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 |
…e intermediate commits are included without defining branch, the second checkout would skip previous automatic commits see actions/checkout#439
…e intermediate commits are included without defining branch, the second checkout would skip previous automatic commits see actions/checkout#439
that was related to this issue actions/checkout#439
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.
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.
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.
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.
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).
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 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 By setting the 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:
I run these tests on all the runner images available ( 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: |
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)
many thanks schnerring, using this method based on GITHUB_OUTPUT it worked beetwen different jobs, thkns! |
always checkout latest version of the data repo see https://github.com/actions/checkout and actions/checkout#439
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)
From the docs:
|
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 So, for any of you checkout@v4 folks this is what worked for me:
|
What the hell, I was thinking I was popping crazy pills, how is this even an issue. |
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.
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.
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.
Thanks folks. This saved me a ton of headache. |
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
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:
The text was updated successfully, but these errors were encountered: