1297162 - Jobs with "file_patterns" run when they shouldn't on the autoland branch

Status: VERIFIED FIXED

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Andrew Halberstadt [:ahal]]

If you look at autoland, you'll notice that often jobs with 'file_patterns' are being run on pushes they shouldn't. For example, the flake8 linter is run even when the push doesn't modify any python files.

I believe this is because the scheduling logic looks at the files touched by all draft ancestor commits. Autoland appears to be non-publishing, which means commits from previous pushes will help trigger the "file_patterns" clause.

So either the scheduler should be smarter and start looking at the pushlog, or autoland should be publishing. I have a hunch the former would be the preferred solution.

Comment 1

[Gregory Szorc [:gps]]

The decision task queries an API on hg.mozilla.org to retrieve info about "relevant" changesets for a push. Changing its behavior on hg.mozilla.org to treat autoland specially is not out of the question.

We /could/ implement this functionality in-tree if we wanted. At the time I implemented it, the decision code was in a much wonkier state and doing it server side was simpler. I'm not opposed to changing it.

Comment 2

[Andrew Halberstadt [:ahal]]

I guess ideally it would be in-tree, but I can't imagine this needing to change *too* much after special treatment in autoland is fixed up. So if leaving it server side is easier that would be fine with me too.

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

My impression is that json-automationrelevance is pretty much designed to feed info to decision tasks, so it seems most reasonable to just modify that to return the appropriately-shaped results.  I assume moving this to the decision task would require more HTTP requests, and thus be a bit slower..

Comment 4

[Gregory Szorc [:gps]]

Moving json-automationrelevance behavior into the decision task requires the decision task to perform VCS commands. It /may/ require the decision task to query pushlog data, which either requires installing a Mercurial extension to sync the pushlog data or potentially multiple HTTP requests to hg.mozilla.org's JSON APIs. At the point you are making a HTTP request to hg.mozilla.org, you might as well expose a single endpoint so the client gets all the info it needs in one go so things are fast.

I'm not super keen on automation syncing down pushlog data because the support for syncing pushlog data is either a) designed for a straight 1:1 replication system b) in the mozext extension, which is not production quality. On top of that, it adds overhead.

Comment 6

[Gregory Szorc [:gps]]

I'll fix this.

Comment 7

[Gregory Szorc [:gps]]

Attachment: hgmo: add config option to control and change default behavior of automationrelevant (bug 1297162);

The automationrelevant() revset determines what changesets are relevant
to automation given an input changeset(s). It essentially allows
automation to see what file changes should influence scheduling.

At the time it was implemented, the only non-publishing repository
that automation ran against was Try. Try is special in that heads
on Try are often pushed on top of previous non-public heads. We want
scheduling on Try to be influenced by non-public changesets from
previous pushes because "unfinished" work should continue to
influence scheduling.

The "autoland" repository has since been introduced and it is also
non-publishing. However, draft ancestors from previous pushes
are effectively "finished" and not relevant to automation scheduling.
The behavior of the revset to union with draft ancestors meant that
scheduling on "autoland" frequently brought in file changes from
dozens of draft ancestors from previous pushes that shouldn't have
been influencing scheduling on this repository.

This commit introduces a config option for controlling the behavior
of adding draft ancestor changesets to the "automation relevant" set
so both Try and "autoland" behave the way they should.

We may introduce automation to more non-publishing repositories in
the future. My guess is these repositories will behave more like
"autoland" than Try with regards to the automation relevance of
draft ancestors. Therefore, this commit changes the default behavior
to *not* union with draft ancestors. This means we'll have to update
a config option on the Try repository to maintain current behavior.

Review commit: https://reviewboard.mozilla.org/r/91236/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/91236/

Comment 8

[Steven MacLeod [:smacleod]]

Comment on attachment 8808426 [details]
hgmo: add config option to control and change default behavior of automationrelevant (bug 1297162);

https://reviewboard.mozilla.org/r/91236/#review91576

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/hgcustom/version-control-tools/rev/8a6f5516bb64
hgmo: add config option to control and change default behavior of automationrelevant ; r=smacleod

Comment 10

[Gregory Szorc [:gps]]

This is deployed. I spot tested that queries to the autoland repo (such as https://hg.mozilla.org/integration/autoland/json-automationrelevance/05db990f8787e761f12418ec2da0f7d4a7cc04fe) are now returning only changesets in the push itself. And queries to Try (whose hgrc I hacked up to use the new config option) are returning draft changesets from previous pushes (e.g. https://hg.mozilla.org/try/json-automationrelevance/586472f6f477).