Hi Andreas, Andreas Enge <andr...@enge.fr> writes:
> [..] > > This should not be confounded with a merge train. If I understand it > correctly, a merge train of n commits consists in letting the ci system > run in parallel all 2^n-1 combinations of including a commit or not; > then out of the succeeding runs, it chooses one with a maximal set of > commits. Given how long it takes to run one evaluation of Guix and build > all its packages, this is not feasible. That is not how merge trains typically work, at least if I understand them right. Quoting from GitLab's documentation[0]: > Three merge requests (A, B, and C) are added to a merge train in > order, which creates three merged results pipelines that run in > parallel: > > The first pipeline runs on the changes from A combined with the target > branch. > The second pipeline runs on the changes from A and B combined with the > target branch. > The third pipeline runs on the changes from A, B, and C combined with the > target branch. > > If the pipeline for B fails: > > The first pipeline (A) continues to run. > B is removed from the train. > The pipeline for C is canceled, and a new pipeline starts for the changes > from A and C combined with the target branch (without the B changes). > > If A then completes successfully, it merges into the target branch, > and C continues to run. Any new merge requests added to the train > include the A changes now in the target branch, and the C changes from > the merge train. So for N pull requests, it should -- absent any failures -- run the build pipeline N times. 0: https://docs.gitlab.com/ci/pipelines/merge_trains/ -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
