[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Indication of build failure from substitute servers?
From: |
Ricardo Wurmus |
Subject: |
Re: Indication of build failure from substitute servers? |
Date: |
Tue, 06 Aug 2024 11:00:59 +0200 |
Marek Paśnikowski <marek@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