It appears that CircleCI’s GitHub Check status refers to the most recent workflow execution result for the head commit, regardless of the branch. So it can lead to cases where results from a different branch are used.
While this may be usually not a problem since the build results for the same commit should be same, it is inconvenient in scenarios such as:
- When
Only build pull requests
is enabled. - When the build takes time.
For instance, in a repository where Only build pull requests
is enabled, the following situation can occur:
- Push branch-a to GitHub.
- Workflow 1 runs and finishes as
Not Run
because branch-a is not associated with pull requests.
- Workflow 1 runs and finishes as
- Create a pull request #1 from branch-a.
- Workflow 2 runs and finishes as
Success
. - The result of workflow 2 is displayed in the checks of pull request #1.
- Workflow 2 runs and finishes as
- Push branch-b, with the head commit being the same as branch-a.
- Workflow 3 runs and finishes as
Not Run
because branch-b is not associated with pull requests. - The result of workflow 3 is displayed in the checks of pull request #1 because the head commit of branch-a and branch-b is the same. This makes the check result of pull request #1 not successful.
- Workflow 3 runs and finishes as
Even if Only build pull requests
is not enabled, the pull request checks will still go pending each time a different branch with the same head commit is pushed.
It appears that GitHub Status Updates do not have this issue. Is there a way to prevent GitHub Checks from referencing execution result of different branches?