Run child jobs in sequence?

Based on some tests that we did while monitoring resources, I think this is a good idea. Only automatic / scheduled runs should be affected. And single child pipeline runs should remain unchanged (and therefore around 10 mins total).

So +1 on doing this.

I think this is ready to review.
MR: https://git.drupalcode.org/project/drupal/-/merge_requests/5584/diffs

Things I did in the MR:

• I defined the initial matrix and made all jobs available on MR, as they are now. The difference is that these jobs are only available on MRs.
• Then I created jobs to be run on commit, that extend the previous ones, and only run on commits. These are run
• Then I did the same for the schedule jobs, that extend the initial ones, and only run on schedule.
• The Default job runs on all three cases.

The MR scenario is easy to test, with this issue's MR. ie: https://git.drupalcode.org/issue/drupal-3404487/-/pipelines/56778

I wanted to test the "on-push", so I created a new branch, without MR linked to it, and added a special workflow rule like this: https://git.drupalcode.org/issue/drupal-3404487/-/blob/3404487-test-comm... and also COMPOSER_ROOT_VERSION: "11.x-dev" for this test.
We can see the pipeline running as expected and with the expected jobs: https://git.drupalcode.org/issue/drupal-3404487/-/pipelines/56789. The jobs also ran in order, first default, then the next, then the next.

First:

Second (which was triggered right after the first one finished):

Based on the screenshots this seems fine?

Should we merge run-on-mr rules into the default block? Then we can remove run-on-mr from each of the main MR jobs, and override the rules for the default, commit and daily cases?

edit: no, because this would break or need overriding in the build and lint jobs

As with a lot of these CI changes the only real way to test is to run with them in production for a while and see what happens.

Committed and pushed fe8bed7bbe to 11.x and 327ddf5a56 to 10.2.x. Thanks!

Hm, the problem now is that if we have a random failure, it appears to stop the subsequent jobs from trying to run: https://git.drupalcode.org/project/drupal/-/pipelines/56988

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Re #11, we could maybe put allow: failure in the sequence, but then we wouldn't be able to tell the difference with real failures.
We could also maybe have a retry, but again, no way to know real failures from random ones.

The random ones are being worked on #3403162: [investigation] get metrics of request to see which settings need to be changed for random failures. I'm planning to leave an MR ready where I think I'm fixing some of them, but probably not all. I'll leave the markTestSkipped for those that I can't fix so far.

If allow: failure just means the job can continue but we still get a green tick in the pipeline UI if the previous job succeeded, and a red cross otherwise, I think that might be ok for the commit/daily tests? We don't want that for the MR tests though.

Testing https://git.drupalcode.org/project/drupal/-/merge_requests/5609
In the test-branch here: https://git.drupalcode.org/issue/drupal-3404487/-/pipelines/57171

Now hoping for a fail somewhere in the chain...

If what I've done does what I believe should do. Fail on the default pipeline on MR will show up as fail, but fails in on-push or daily will just show up as warnings.

It worked as I expected. The whole pipeline run even if the second one had a fail. That marks the parent pipeline as "Warning", which I think it's what we want here.
https://git.drupalcode.org/issue/drupal-3404487/-/pipelines

Yep, this seems like the best compromise for now.

Committed and pushed e687d46ec7 to 11.x and 4ae3c26580 to 10.2.x. Thanks!

Please close MRs