Merge commit ref shouldn't stay same after changing base branch for a PR

[mqasimsarfraz]

We know that the workflows triggered via pull_request event uses merge commit as GITHUB_SHA. Now I would expect that if we change the base branch (using 'edit' button on the pull request in GitHub UI) there would be a new merge commit and that should be used if I trigger the workflow. But with my testing the action/checkout still uses old merge commit from previous base branch. If I push any further commits everything works as expected and action/checkout fetches the updated merge commit.

Steps to reproduce

Assuming you have workflow triggered on all pull_request events:

1. Create 3 branches foo, bar, foobar
2. Create a PR from foo in bar.
3. Check the fetched ref in action workflow logs.
4. Change the base branch from bar to foobar
5. Trigger the action again.
6. The fetched ref should be same as step 3.

Workaround

• Push new commits to propagate the merge commit change.
• Specify the job ref in step to make sure it has updated value for example

Comments

I know it might be the limitation of the system but wanted to open the issue so more people are aware of it.

[alsora]

Hi, I think I'm seeing a similar problem, although in my case I'm using only 2 branches.

1. Create a PR from foo to bar
2. pull_request event triggers the action as expected.
3. Push new commit to bar (i.e. the target branch of the PR)
4. Manually run again the action in the foo to bar PR

I would expect step 4 to evaluate again how to checkout the repository, however I noticed that it will still use the old version of bar, thus ignoring the added commits of step 3.

Is there a way to "force" the github action checkout to re-evaluate the target branch?

[mqasimsarfraz]

I would expect step 4 to evaluate again how to checkout the repository, however I noticed that it will still use the old version of bar, thus ignoring the added commits of step 3.

Isn't this by design? like it would be expected from the PR owner to rebase the PR to reflect such changes. I do see there is a faster way to rebase or am I misunderstanding it?

[alsora]

A rebase is not necessary in this situation and it would be the wrong way to solve the problem.
A PR targets the head of a branch, not a specific commit, and this already works in github as expected.
It's only an issue of this action that caches the old head hash and re-use it when re-triggering a workflow

[mqasimsarfraz]

Ah now I get it. Thanks for clarifying. Definitely, the action uses incorrect/outdated merge commit in some cases. It has been couple of months since I opened this issue. Not sure if there is a way to escalate this?

[xer0x]

+1 we occasionally hit this too. It can waste a lot of time to debug.