-
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 for PR is not simulating a merge with HEAD of main
#696
Comments
We've observed similar when rerunning jobs. It uses the same merge commit that was present when the job was originally run, as opposed to a more up to date merge commit. |
Check the github context The default checkout by EDIT: I'm mistaken, as @millerick pointed out, this is not the case with workflow job re-runs. It seems that the test merge commit ( Types of merging for branches (unrelated to action)Merge Commit - History of PR commits retained (distinguishable from other commits in branch)When it comes to merging the PR, my understanding is that a merge commit itself is empty and the history of your commits on the base branch can be spread out based on the date of each commit (I did this to retain history over the years of our GIthub Wiki when migrating it's commits into the main repo). So it'd make no difference where the merge commit itself was placed if your associated commits from the PR will always be in the same place. Only if there was a conflict from newer commits, would that need to be resolved, and thus newer commits in the PR history would have addressed that (bumping up the merge commit itself). Rebase - Merge by rebasing commits (no history interleaving, no merge commit, not distinguishable as it's own subset of commits in the branch)If you do not want the merge commit in your history, and want your PR commits added on to the top of the base branch head, then you need to change the merge option for your PRs from a "merge commit" to "rebase". "Rebase" will rebase the PR history on top of the base branch history, no merge commit will be added. The extra line in your screenshot showing all those commits belonging together would be lost, and it'd appear like above all on the blue line (no distinctive grouping of the PR commit history, where the commits started and ended, just commits). Squash - Merge by squashing all commits into 1 (with reference to PR page)If neither of those sound appealing, you may prefer the "squash commit" type of merge. This is my preference. It will combine all the PR commits into a single commit which is added to the top of your base branch. The commit has the full diff and by default the commit title should include a reference link to your PR (useful for With the squash commit, you generally get a cleaner commit history, but Action behaviour
Just tried that and was surprised that happened. (UPDATE: It seems like the merge commit is cached, possibly to make re-runs more deterministic) So...
UPDATE: I tested this with another commit pushed to the PR branch too and re-running the workflow job from the previous commit. The job continued to use the outdated base branch HEAD commit from when that commit was pushed (thus cached, not generating a new/different merge commit). I also noticed that other Github context was also cached for that commit at it's time. Such as the number of commits the PR has. That caused my workflow to fail as it lacked the |
I am running into some issues, because checkout action is doing a merge of PR into wrong SHA.
When running checkout on this repository:
https://github.com/raycast/extensions
You can see unwanted behaviour here:
https://github.com/raycast/extensions/runs/5185777181?check_suite_focus=true#step:2:486
It merged the
HEAD
of PULLREQUEST with some random commit frommain
-cd113f35
.It looks like this visually:
Red arrow is how the merge is done now, green is how I would expect it to work.
What I think should be happening here is that PR should be done between
4706f01c76ef11c4220e9f81e99e13cc58e80642
andde0735da937fb75489043e4ed89e5d96a6b4dbeb
.This is maybe because this PR is coming from a forked repository.
The text was updated successfully, but these errors were encountered: