A semantic conflict might happen if two PRs are merged at the same time with their CI checks from the same base. Even though the individual checks work out fine and the combination git merges without issue, they might fail.
An example would be one PR requiring each feature to be present in both Makefile.dep and Kconfig, and another PR adding a feature to just one of them. When merged at the same time, they conflict.
Rust is using a tool called borg to prevent this. See https://bors.tech for more info.
I don’t think this is feasible for RIOT-OS/RIOT ATM for performance reasons, but I’d like to set this up for RIOT-OS/riotdocker. In that repo, we already require the CI results to be from a build agains current master, requiring quite some manual rebasing and rebuilding.
What do you think, should we give this a try for the riotdocker repository?
Well, CI does test and only allow merging when the tests pass. On RIOT-OS/RIOT, there can still be semantic conflicts, because the test result is not invalidated on master merge.
bors would, when you comment “bors +r”, collect currently waiting PRs, push them to the “staging” branch, build them all in combination against the current master, then merge on success.
It would replace the regular “press merge button to merge” workflow.
For riotdocker, we do invalidate outdated test results. So if multiple PR’s have passed tests, then one gets merged, the other PRs need to be rebased (IIUC) to trigger a re-build against current master.
bors would do that, and if there are multiples that do that at the same time, merge them together and then if the tests succeed, merge into master together.