Open Bug 587344 Opened 9 years ago Updated 2 years ago

Before offering an update, check that the build starts up afterwards

Categories

(Release Engineering :: General, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: khuey, Assigned: sfraser)

References

Details

This is fairly easy after the packaging refactoring patches I have.
Can't be done on the client side so over to releng
Component: Application Update → Release Engineering
OS: Windows 7 → All
Product: Toolkit → mozilla.org
QA Contact: application.update → release
Hardware: x86 → All
Version: unspecified → other
I pulled all the mar files and the exe from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-11-06-mozilla-central/. 

The exe contains chrome.manifest at the base level, as expected from a manual install working. The complete update contains both chrome.manifest and a REMOVE instruction for that in update.manifest (from the really old line in removed-files.in). The partial doesn't contain chrome.manifest but does have the REMOVE instruction. I think it doesn't contain an ADD instruction because the file is present in the 2010-08-10 nightly, or a PATCH instruction because the file didn't change between the 10th and 11th.

So the bug is that the file's existence contradicts the entry in removed-files.in. Or that package-manifest.in contradicts removed-files.in, modulo there being a bunch of #ifdef's in both which make that easier to resolve at build time.

We could fix the manifest generation to only give one instruction per file, and make the build go orange to flag the problem. Or error out if removed-files.in refers to files that are to be packaged, make the build go red, and not publish the nightly. Note that this won't show on depend builds when the change lands, but the first nightly afterwards. What do you think ?
> We could fix the manifest generation to only give one instruction per file, and
> make the build go orange to flag the problem. Or error out if removed-files.in
> refers to files that are to be packaged, make the build go red, and not publish
> the nightly. Note that this won't show on depend builds when the change lands,
> but the first nightly afterwards. What do you think ?

This is what I had in mind.
Which of the two suggestions there do you mean ?
(In reply to comment #4)
> Which of the two suggestions there do you mean ?

khuey, ping?
The latter, make the build die completely.
Assigning this to Nick because he seems to know what's going on. Please feel free to throw it back if you think that's wrong / don't have time.
Assignee: nobody → nrthomas
Going to be a bit longer until I get to this.
Priority: -- → P3
Found in triage.
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: catlee
Product: mozilla.org → Release Engineering
This is part of the plans around build promotion, where the aim is to ship the builds from the initial code landing. rstrong has requested this test as part of the discussions around that project; at this point we're thinking marionette is the way to go.
Assignee: nthomas → nobody
Summary: Write checks to prevent a recurrence of Bug 586350 → Before offering an update, check that the build starts up afterwards
Assignee: nobody → sfraser
I know this is still wanted/needed, but is it done?
We have builds that are tested, and we promote them. The question is whether this test is one in the critical path to shipping, so a failure blocks shipping.
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.