Steps to reproduce
- Make a workflow with trigger:
on: [ pull_request ]
- Make a change on the
mainbranch that makes the workflow fail
- Make a feature branch called
my_featurethat makes a change that is totally unrelated to the failure on main, that passes the workflow if “on: [ push ]” would have been used.
- Create a PR from my_feature branch to main, this will cause the on: [ pull_request ] to be triggered and fail because of 2.
- Fix the workflow failure on main
- Rerun the workflow on the my_feature → main pull request.
Actual behaviour in step 6:
The rerun of the on: [ pull_request ] workflow fails. The rerun is being run on the result of the merge of my_feature branch with “main at the time of the latest commit on my_feature”.
Expected behaviour in step 6:
Since the workflow failure in main has been fixed. I would expect the rerun of the on: [ pull_request ] workflow to pass. I would expect the rerun to actually run the workflow on the merge of my_feature branch with “main at the time of the rerun”. When checking wether it is safe to merge a feature branch into main, I don’t care what the result of CI is when merging into the main branch at some point in the past. I care about what the result is of merging into main is, the way main is right now.
Another solution that would also work for, is actually to automatically create a new run of the pull_request workflow every time the target (main in this case) branch is updated, and not only when the source (my_feature in this case) is updated. Although this might lead to a load of extra CI execution if you have a lot of pr’s open to main.