Note: There are a few cases of duplicates in user autocompletion which are being worked on.

don't wait for all platforms to finish before running update verify

NEW
Unassigned

Status

Release Engineering
Release Automation
P3
normal
3 years ago
a year ago

People

(Reporter: bhearsum, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
Update verify currently runs after the "updates" builder because we have to wait for all platforms to finish their build/repacks before we can create and push snippets.

Once Balrog is being used for betas/releases we'll have all the data we need for update verify in Balrog as each platform finishes. Given that, there's really no reason to artificially delay running it until later. This won't really help with end to end time, as Windows repacks + update verify are still critical path, but it would help in situations where Linux or Mac becomes the long pole because of issues, and should help take some load off of FTP, too.

We'd need a few tweaks to do this. At least the following:
* Move initial balrog blob submission/test channel updates to the start of the release process
* Get rid of the updates builder complete
* Generate update verify configs elsewhere (perhaps in each of the update verify builders -- there's no reason we have to keep a checked in version now that they're generated based on the patcher configs).
* Adjust schedulers roughly as follows:
tag -> {initial balrog,linux build,    linux64 build,    win32 build,    mac build}
                           |                 |                 |              |
                       linux repacks   linux64 repacks   win32 repacks   mac repacks
                           |                 |                 |              |
                       linux uv        linux64 uv        win32 uv        mac uv
                           \-----------------\-------|---------/--------------/
                                                     |
                                              ready for release

check permissions, antivirus, etc. would still trigger off of the "deliverables ready" scheduler and feed into "ready for release" (in addition to the update verifies in the graph above)
(Reporter)

Comment 1

3 years ago
There's probably still an additional blocker to this - we won't be getting rid of the updates builder completely as part of bug 933414.
(Reporter)

Updated

3 years ago
Priority: -- → P3
(Reporter)

Comment 2

3 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #1)
> There's probably still an additional blocker to this - we won't be getting
> rid of the updates builder completely as part of bug 933414.

The additional blocker is more or less "move top level balrog submission to start of release process". Basically, we need to split https://github.com/mozilla/build-tools/blob/master/scripts/updates/balrog-release-pusher.py into two scripts: one that runs ReleaseCreator, and one that runs ReleasePusher.

If we do that, the rest of this bug is just adjusting the update verify schedulers to fire after each platform's repack_complete builder finishes.
What would run the ReleasePusher part ? An cut-down updates builder ? :-P  We could have separate platform rules, but instead of splitting we could just run it all early. ie point test channels at the new release straight away, and don't mind no updates until repack_complete comes in.
(Reporter)

Comment 4

3 years ago
(In reply to Nick Thomas [:nthomas] from comment #3)
> What would run the ReleasePusher part ? An cut-down updates builder ? :-P

Depends on where we want to do update verify config bumping. We could do it with ReleasePusher or ReleaseCreator. Either way, it might be a good time to move some of this to Mozharness.
 
> We could have separate platform rules, but instead of splitting we could
> just run it all early. ie point test channels at the new release straight
> away, and don't mind no updates until repack_complete comes in.

Good idea.

I also realized that QA can probably start their update tests earlier, too. We should consult with them if/when we do this.
This should be easy to do in relpro.
Blocks: 1118794
You need to log in before you can comment on or make changes to this bug.