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:

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?

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 ✨ [investigation] get metrics of request to see which settings need to be changed for random failures Active . 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, I think that might be ok for the commit/daily tests?

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

I think we could consider halting the child runs on a fail (to save 10 environments telling us we made a bad commit), but we probably only once we've got very infrequent random test failures, so +1 for doing this.

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

Automatically closed - issue fixed for 2 weeks with no activity.