Closed Bug 588396 Opened 14 years ago Closed 3 years ago

run update verify on nightlies

Categories

(Release Engineering :: General, defect, P5)

Product:
Release Engineering
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bhearsum, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [updates])

Omnijar was backed out because updates were broken. To help reduce the frequency of breaking nightly updates and the window in which their broken we should run update verify tests on nightlies. Ideally, we'd run this post-build but prior to publishing the update. If update_verify fails, the update should not be published, I think.
A bit more detail: Specifically, we'd be doing the "compare update applied against previous build to current build" part of update verify. We wouldn't be able to use AUS.
Priority: -- → P5
Given the discussion on bug 498425 would that be the right place to have Mozmill tests in place for nightly builds? Which means that those test can be run before we offer the updates on the nightly channel? As given the info from coop we do not have a test channel for nightlies yet. It's probably something we could add here?
OS: Mac OS X → All
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: release → catlee
Whiteboard: [updates]
Ben, we will have a CI system up shortly which let us run all kind of tests against daily builds of Firefox. It doesn't match your criteria by doing it before we publish the update to our users, but would there be an option we could do that, ie. by using a specific update channel?
(In reply to Henrik Skupin (:whimboo) from comment #3) > Ben, we will have a CI system up shortly which let us run all kind of tests > against daily builds of Firefox. It doesn't match your criteria by doing it > before we publish the update to our users, but would there be an option we > could do that, ie. by using a specific update channel? Not at this time. Right now, the only place you could test updates prior publishing is as part of the build =(.
Product: mozilla.org → Release Engineering
Component: General Automation → General

Can we rescope this slightly to run a modified update-verify process for nightlies?

We can fetch the current and previous mar files directly given information in the taskgraph. We can fetch the linux64 updater binaries from the linux64 build, and then use it to verify that all the nightly updates can be applied and result in the correct end-state. In this way we could avoid a dependency on AUS, and be able to block publishing updates until they've been tested.

(In reply to Chris AtLee [:catlee] from comment #5)

Can we rescope this slightly to run a modified update-verify process for
nightlies?

We can fetch the current and previous mar files directly given information
in the taskgraph. We can fetch the linux64 updater binaries from the linux64
build, and then use it to verify that all the nightly updates can be applied
and result in the correct end-state. In this way we could avoid a dependency
on AUS, and be able to block publishing updates until they've been tested.

This probably wouldn't be very hard. https://dxr.mozilla.org/mozilla-central/source/tools/update-verify/release/common/check_updates.sh wants the path to two MARs on disk (as well as a few other things), and it should run the test and give you pass/fail.

We have startup tests for nightlies.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Blocks: 1837440
You need to log in before you can comment on or make changes to this bug.