1710592 - Generate bugbug-push-schedules.json artifact on backstop pushes too

Status: NEW

(Firefox Build System :: Task Configuration, task)

Description

[Marco Castelluccio [:marco]]

The absence of the artifact can make some analyses harder.

Comment 1

[Marco Castelluccio [:marco]]

Andrew, how hard would this be?

We could trigger the bugbug requests in the background and not actually wait for them, and at the end write the artifact if we got the reply in time.

Comment 2

[Andrew Halberstadt [:ahal]]

I don't think it would be too hard to hack in..

Though it would actually be pretty nifty to have a mechanism to trigger background jobs at the start and then block on the result at some arbitrary later point in the generation. I'd like this feature for reading the test manifests as well. So it might be worth putting a bit of thought into the implementation here.

I'm also trying to consolidate the code bases of the two taskgraphs, so I'll push back against any implementation that involves adding this feature into "core" files like generator.py.

Comment 3

[Marco Castelluccio [:marco]]

(In reply to Andrew Halberstadt [:ahal] from comment #2)

I don't think it would be too hard to hack in..

Though it would actually be pretty nifty to have a mechanism to trigger background jobs at the start and then block on the result at some arbitrary later point in the generation. I'd like this feature for reading the test manifests as well. So it might be worth putting a bit of thought into the implementation here.

Note I was not thinking of not waiting as a hacky solution, but just because we don't actually need the results from bugbug in the backstop pushes, so if it's taking too long it's better to finish the task rather than to wait the full timeout (I'm also OK if we want to wait, in the end it's just the backstop pushes, so very few compared to all other pushes where we already wait).

We could design the "background jobs" feature in a way that allows both to wait for results or not (e.g. triggering a job could return a future which the users can await on or not depending on their needs).

Comment 4

[Andrew Halberstadt [:ahal]]

Yeah, using a future was exactly what I was thinking here. This way it can be up to the consumer to decide what to do with the result.. block or cancel.