Marek Paśnikowski <ma...@marekpasnikowski.pl> writes: > The proof of availability is in workflow itself. The project committers > NEVER commit anything to the master branch. Only the CI system > does. Instead, the committers push to a "pre-main" branch, and the CI > system picks the commits up one by one and attempts to build them as > usual. IMPORTANT POINT: *if* the commit builds correctly, it gets pushed > by CI to master branch, and the substitute is already available. *If* > the commit does not build, it gets rejected, and it never goes to > master. > > I currently do not know enough about Git to confidently propose a > solution to the problem of how to handle the reordering of the queued > work on a build failure, but I have a feeling it is not that hard to > solve.
Prior art: https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html An open problem is preserving commit signatures or perhaps changing the meaning of signatures by signing not the commit but the changes only. -- Ricardo
