The job simply checks, if the feature branch base is the head of the current dev branch. If not, at least one GitHub Action fails and the merge is blocked.
The idea is motivated by the behavior of our current CI. It does not automatically rebase. Therefore it is possible, that the CI tested an outdated version, GitHub is fine, because there is no merge request, we merge it and the dev branch CI failes, because the last commit before the merge introduced a new bug.
We should also not automatically rebase in our CI, because if develop an long time PR and has an bug inside, if it automatically rebase you don't know if your bug is still in the developers implementation or maybe a bug introduced by the dev branch.
Possible problems
- Between the check job was executed and the merge it is possible, that another PR is merged. Let's see, if GitHub has a solution. Maybe there is a pre-merge hook.
- This can slow down our development. If a trivial PR was merged, we have to rebase and run the CI again (which can take about 2h) independent what the other PR did. @fwyzard @psychocoderHPC any opinion on this problem?
The job simply checks, if the feature branch base is the head of the current dev branch. If not, at least one GitHub Action fails and the merge is blocked.
The idea is motivated by the behavior of our current CI. It does not automatically rebase. Therefore it is possible, that the CI tested an outdated version, GitHub is fine, because there is no merge request, we merge it and the dev branch CI failes, because the last commit before the merge introduced a new bug.
We should also not automatically rebase in our CI, because if develop an long time PR and has an bug inside, if it automatically rebase you don't know if your bug is still in the developers implementation or maybe a bug introduced by the dev branch.
Possible problems