verify mar integrity for nightly builds
Categories
(Release Engineering :: General, enhancement)
Tracking
(firefox150 fixed)
| Tracking | Status | |
|---|---|---|
| firefox150 | --- | fixed |
People
(Reporter: bhearsum, Assigned: bhearsum)
References
(Depends on 7 open bugs, )
Details
(Whiteboard: [updates])
Attachments
(11 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
This was originally https://bugzilla.mozilla.org/show_bug.cgi?id=588396, but that bug was closed without the issue actually being fixed.
Essentially, we should run our existing update-verify tests on Nightly. These tests are responsible for verifying that installers and updates get a user to the same place, and typically catch issues where an installer or MAR is missing a file or has one that it shouldn't.
This came up recently after a change to macOS notarization was made which caused us to drop a file accidentally. (See https://github.com/mozilla-releng/scriptworker-scripts/pull/761.)
These tests don't necessarily have to block shipping each Nightly update. Even if they ran after the fact it would be a big benefit, and prevent the issue above from hitting Beta or Release.
As the original bug notes, we could (and maybe should) run these tests in a way that bypasses the need for Balrog. This isn't strictly necessary if we accept that Nightly will ship before update verify runs, though.
| Assignee | ||
Comment 1•2 years ago
|
||
jcristau suggested that we add a new task downstream of repackage (or maybe repackage-signing) that could do the "compare MAR to installer" part of update verify, which is the main part we're concerned about. This would essentially function like a unit test in that it only requires data from the upstream task to run, making it a very tractable solution.
Updated•1 year ago
|
Comment 2•1 year ago
|
||
:jlorenzo adding a note, in the Fx136 cycle we hit issues with UV tests.
- 136.0b1 required 4 respins before the tests were fixed.
- 136.0 RC1 was followed by a quick fix in 136.0 RC2.
This was mentioned in the Fx136 retro. Wondering if there is any priority on this bug?
Catching failures in Nightly would have saved a lot of back-and-forth.
Hey :dmeehan! I totally agree. I'm getting the leadership approval to get this prioritized in FFXP-3289.
Updated•1 year ago
|
| Assignee | ||
Comment 4•26 days ago
|
||
I've been working on getting something up and running that does the mar integrity part of these checks, which (as noted in comment #1) is the main part we care about for Nightly.
I should have a patch stack to share soon; I plan to land it as a fairly minimal MVP and iterate from there, so this may branch out into a number of other bugs.
| Assignee | ||
Comment 5•25 days ago
|
||
Updating the title to reflect what's actually going to happen.
| Assignee | ||
Comment 6•25 days ago
|
||
This is a bit of a weird assumption to make, and while it works for the current update verify tests, it restricts our ability to call this function from elsewhere.
| Assignee | ||
Comment 7•25 days ago
|
||
Notably without:
- A config file
- Downloading anything as part of the test
This means the caller is responsible for figuring out and acquiring the files and information necessary to run the test, which allows for more flexibility. ie: we can start putting that logic in a caller other than verify.sh.
| Assignee | ||
Comment 8•25 days ago
|
||
This allows callers to better understand failures.
| Assignee | ||
Comment 9•25 days ago
|
||
This doesn't matter for verify.sh, where we always have build targets available, but build targets aren't strictly the only way to identify platforms, and it would be nice to have to use them when running check_updates.sh in a context where they aren't otherwise needed.
| Assignee | ||
Comment 10•25 days ago
|
||
While it would be strictly ideal to do it, requiring both MARs to be signed with the same certificate means that partials tasks cannot work on Try without 2 try runs (one to generate completes signed with the dep cert, another that generates partials). Disabling this allows us to generate partials off of production releases, which speeds up testing cycles.
| Assignee | ||
Comment 11•25 days ago
|
||
This is necessary for diff analysis of a production nightly with a MAR from Try applied to vs. a Try build to pass.
| Assignee | ||
Comment 12•25 days ago
|
||
Further down this stack I'm adding a new Rust tool that lives in the tree and is built by a toolchain task. Running the tests in the toolchain task is not strictly the ideal, but I'm not aware of any solution we have for running tests in a downstream task. (An alternative might be to add a separate task that does the build and runs the tests, but that seems even less ideal.)
| Assignee | ||
Comment 13•25 days ago
|
||
This is about as much of an MVP as we can have, while still being able to run it against Linux x86-64 en-US nightlies on mozilla-central. It may need additional work to be able to test other platforms (including Linux aarch64) and locales. I think that work is rightly done in follow-up patches, as is any work to get rid of the dependencies on existing shell and python scripts.
| Assignee | ||
Comment 14•25 days ago
|
||
I'm not 100% certain this is the best way to do this, but it seems roughly inline with how we deal with other Rust based tools.
| Assignee | ||
Comment 15•25 days ago
|
||
This is useful when grouping by multiple upstream kinds, only some of which contain l10n tasks.
| Assignee | ||
Comment 16•25 days ago
|
||
This explicitly only supports linux x86-64 en-US nightly builds at the moment. It will need some enhancements to support other platforms as well as l10n builds - but it's a good starting point.
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
Updated•18 days ago
|
| Assignee | ||
Comment 17•18 days ago
|
||
This initial work will soon land. I'll be filing separate bugs for a bunch of follow-on work (running tests on different platforms, for localized builds, and some other things).
Comment 18•18 days ago
|
||
Comment 19•18 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/6a7dbf5ce87e
https://hg.mozilla.org/mozilla-central/rev/6b77574aba7d
https://hg.mozilla.org/mozilla-central/rev/678f0228dd5a
https://hg.mozilla.org/mozilla-central/rev/709218bee6bf
https://hg.mozilla.org/mozilla-central/rev/7f39be4fe754
https://hg.mozilla.org/mozilla-central/rev/37d4bbab1313
https://hg.mozilla.org/mozilla-central/rev/ba2e512cef09
https://hg.mozilla.org/mozilla-central/rev/203a39b4d3d6
https://hg.mozilla.org/mozilla-central/rev/1ebf699b3858
https://hg.mozilla.org/mozilla-central/rev/d36d68b908db
https://hg.mozilla.org/mozilla-central/rev/411e41a338ff
Description
•