GitHub pull requests will show you validations that Gearset runs and report the validation status.
This sometimes leads to the following unexpected scenario, which we explain here:
You have 3 CI jobs, with validation PR enabled on all, targeting 3 different branches. Say the 3 branches are:
Integration
Staging
UAT
This article explains why the pull request targeting only the integration branch is trying to validate all 3 CI jobs, when users would typically expect only for the integration one to validate in the GitHub pull request.
This is down to some unintuitive GitHub behaviour:
There are other pull requests (the non-relevant ones, targeting Staging and UAT) with the same head commit as the PR open against the Integration branch
Gearset has run a validation for those two pull requests (on Staging and UAT), which Gearset then sent to GitHub
GitHub now has received multiple validation statuses for that commit (3 exactly), and therefore tries to be helpful and shows all the validation statuses for the pull requests, since they're all a status for the same commit
This also appears to be a GitHub only thing, other version control providers are more 'strict' and only show you the validation which is directly relevant for the PR (not for the commit).
Failing validation is blocking my merge
If you have enabled the GitHub setting to Require status check to pass before merging, and depending on your workflow, you might end up in the situation where a non-relevant environment validation failure prevents you from merging.
It should be noted that this situation is usually avoidable by ensuring you restrict the number of open pull requests with the same head commit. Once the PR has been merged (therefore successfully validated), you can then create a new PR and the validation status will not interfere. Should you need to open multiple simultaneous pull requests, then please continue reading below.
GitHub has a setting which allows you to specify which status checks are required before merging. By navigating to: https://github.com/<your-username>/<your-project>/settings/branch_protection_rules/new, you can specify a new rule:
In the example above, we can specify that the branch integration should only be concerned with validations coming from the CI job integration.
This means as long as the Gearset validation check on integration passes, you will be allowed to merge, completely bypassing the non-relevant dev1 checks.
Github's squash and merge
Another interesting scenario with GitHub is how it automatically maps the feature branch that you chose to "squash and merge" to the new squash-merge commit.
To recap, when you choose to "squash and merge", GitHub simply takes all the commits from your feature branch and combines them into a single commit. In the same operation, GitHub will then merge the squashed commit into the target branch. The feature branch itself is not modified.
This means the validation status will now not only appear on the latest commit of the feature branch, but it will also appear on the new squashed commit. Although the two commits have different SHA's, GitHub is intelligent enough to link the two and will therefore show the validation status whenever it comes across one of the two commits. This, like our previous examples, might mean you get the validation appearing for a different branch and a completely different commit.