1496530 - ship and push graphs create broken partner tasks when a new partner is added post-promote

Status: NEW

(Release Engineering :: Release Automation: Other, enhancement)

Description

[Aki Sasaki (not active)]

If someone adds a partner after the promote phase is complete, the push or ship graph will spawn signing and beetmover tasks for that partner. These tasks will fail, because the repack task didn't create artifacts for that partner.

In my mind, ideally we have revisions of these partner configs, and we can point to a static copy throughout all the release's graphs. That could be in-tree, or ship-it v2 could point to a specific revision of the partner configs, or we could have a partner config generation task that they all refer to. However, various people don't like that, and we ended up running partner config generation at action task time. Since we have at least 3 separate action task times, and because we're pointing at the tip of the partner manifests each time, we have this bug.

One solution is for the push and ship graphs to copy the promote task's partner_config from its parameters.yml. This is tricky, because the snowman model doesn't require that the promote graph be in any specific location in previous_graoh_ids, or that we put only a single promote graph in previous_graph_ids. So if we go with this solution, we likely have to download all previous_graph_ids' parameters.yml, and go with either the 1st or final (probably final) non-empty partner_config it finds, and fall back to generating the partner_config.

Comment 1

[Aki Sasaki (not active)]

We could also change the rules, so only tasks that match the current phase run. E.g., if you do a push graph, and there are some promote tasks that didn't run in the previous graph, skip them.

This change would essentially kill any hope of fixing bug 1433488 (skip straight to the push phase). Also, if we wanted to promote a set of builds, but rebuild part of the build graph (e.g., release-sign instead of dep-sign), this change would also make things more difficult. Perhaps ship-it v2 makes things easy enough that this isn't a concern.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Bug 1476065 would like to move the github lookup out of the decision task, so maybe we should do that in ship-it v2 and send it along in the action input for the first action, usually promote_firefox. Ideally we don't have to keep sending that for later actions when they're sent sequentially, like we do for partials in ship_firefox.