Page MenuHomePhabricator

Consider having a top-level jenkins CI job for each commit, so they can be manually killed swiftly rather than one-by-one
Open, Needs TriagePublic0 Estimated Story Points


Rather an edge case, but… :-)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 6 2019, 4:22 PM
hashar added a subscriber: hashar.Jun 6 2019, 6:22 PM

Hmm but why? :-] I am not sure I get the use case for killing jobs?

Hmm but why? :-] I am not sure I get the use case for killing jobs?

Today, for the security release, @Reedy push ~50 pre-C+2'ed patches (~10 patches to master+four release branches); half of these were force-merged, so the Test and Gate-and-Submit pipelines were both unused, and the other half definitely didn't need Test as well. Spending 10 minutes manually killing jenkins jobs to try to get CI to focus on the patches that were actually needing it was a pain.

Not a priority, just a gripe.

Reedy added a comment.Jun 6 2019, 8:40 PM

Well, I C+2,V+2'd,submit 20-25 patches total (REL1_27 and REL1_30), because we knew the patches wouldn't pass CI (due to the node bumps and not backporting the fixes due to them being EOL), and I didn't just want to force push to the branches (so there was still an entry in gerrit)

So this meant, all these patches created test and gate-and-submit tests that we honestly didn't care about the result of.

So to try and save some time, we killed as many tests as we could for jobs we really didn't care about, to try and alleviate the already overloaded queue

So as James says, not a priority, but would be useful in these sorts of cases

For the security release case, which I think is really the only case we want to support skipping CI for, I think we could have some topic/hashtag (if zuul supports those) or a pseudo-header in the commit message (e.g. Wikimedia-CI: skip) that zuul filters on maybe with an email whitelist to approved releasers to not queue any jobs for.

Prior art:

The proposed solution in the task title compromises the performance of everyone's patches just for this one edge case, which I don't think is a good idea.