unit-e
unit-e copied to clipboard
dtr-org
Should pull requests required to be up to date when merging?
There is a small chance that we will bump into the case when merged PR is broken because of the change on a master. But there are already tools that mitigate it: if there is a conflict, you won't merge. At the last commit which is added to PR, the travis build is run on a merge commit with master so the build is "auto-refreshed".
If we enable this tick, it will require us to constantly rebase with master and as you know, it takes really long until you get feedback from Travis. And once someone merged his PR, everyone must do the same.
I have to agree with @kostyantyn. If a pull request breaks the tests because of a problem with updates in the master branch which don't cause merge conflicts, the CI on the master branch will catch it. So there is not much risk that we completely miss a problem.
The chance that a problem slips through the CI on a pull request and only occurs when merged is quite low. And if developers suspect that there might be a problem they can always trigger the CI run by merging master or rebasing against it.
In contrast the additional waiting times because of more CI runs are very real and will happen often, especially when there are multiple pull requests going on in parallel (what usually seems to be the case).
So I think we have a smoother development process with not switching on this flag. In case we often see problems caused by not having it switched on, we can still revisit the question.
