When you create a pull request to merge branch A into branch B on GitHub, the version of the action that will run is the one from the base branch of the pull request, which in this case is branch B[1][8]. This is because GitHub Actions uses the workflow definition from the base branch when processing pull requests.

Here's a breakdown of how this works:

Workflow Execution for Pull Requests

1. Base Branch Workflow: When a pull request is opened or updated, GitHub Actions looks at the workflow files in the base branch (branch B in this case) to determine which actions to run[8].

2. Context of Execution: The workflow runs in the context of the merge commit that would result if the pull request were to be merged at that moment[1].

3. Ignoring Head Branch Workflow: Any workflow files in the head branch (branch A) are not considered for execution in this scenario[1].

Important Considerations

• Workflow File Location: The workflow file must be present in the default branch (usually master or main) for it to run on pull requests[8]. However, the specific version of the action that runs is determined by the base branch of the pull request.

• Consistency: This behavior ensures that the tests and checks run on the pull request are consistent with what will be in place after the merge is completed.

• Security: Running the workflow from the base branch also prevents potential security issues that could arise from running untrusted code from the head branch of external pull requests.

Best Practices

To maintain consistency across your repository:

1. Keep your workflow files synchronized between branches, especially for long-lived feature branches.
2. Use version pinning for actions to ensure reproducibility across different branches.
3. Regularly update your branches to incorporate the latest workflow changes from the default branch.

By understanding this behavior, you can better manage your GitHub Actions workflows and ensure they run as expected across different pull requests and branches in your repository.

Citations:
[1] https://github.com/marketplace/actions/merge-pull-requests-automerge-action
[2] https://graphite.dev/guides/github-actions-on-pull-requests
[3] https://github.com/marketplace/actions/auto-pull-request-merge
[4] https://github.com/orgs/community/discussions/25796
[5] https://github.com/orgs/community/discussions/67160
[6] https://github.com/orgs/community/discussions/65321
[7] https://github.com/orgs/community/discussions/26958
[8] https://docs.github.com/en/actions/about-github-actions/understanding-github-actions
[9] https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue
[10] https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows
[11] https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request
[12] https://www.reddit.com/r/github/comments/1e3lrrd/how_do_i_rerun_github_actions_when_a_new_commit/
[13] https://stackoverflow.com/questions/59077079/how-to-get-pull-request-number-within-github-actions-workflow/69936361