Closed Bug 551638 Opened 11 years ago Closed 8 years ago

Add a buildstep to run |make package-compare|


(Release Engineering :: General, defect, P4)



(Not tracked)



(Reporter: philor, Unassigned)


(Depends on 1 open bug)


(Whiteboard: [automation])

Now that bug 547599 added a package-compare make target to Firefox, it would help to catch packaging screwups if buildbot would run it, at least on build and nightly boxes (and tryserver, though that's probably a dependency of bug 520227), and probably for your own benefit on release builds.

Thunderbird and SeaMonkey are already running it, though I don't know enough about buildbot to know whether that means that they both have patches that they could upstream.
Depends on: 547599
We currently have them running via subclassing in the CC* factories, we should be able to just move that build step into the main classes.
What does package-compare do?
Diffs the preprocessed package-manifest and the list of files in dist/bin, so you can see what was built but not packaged and what was supposed to be packaged, but wasn't there. It's noisy, and thus has to be just manually examined, so far, since it doesn't know to expand directories and doesn't have an exclusion list for things like xpt_link that we know we build and intend not to ship, but once you learn to read past those (or, better yet, once someone decides to fix those so they don't have to read past them), tells me that we still need to stop trying to package contentprefs.xpt since it's gone, but that nobody has added anything new without remembering to package it.
Realistically, this probably won't happen soon.
Priority: -- → P4
Probably just as well: it's not quite entirely blocked by bug 490223, but having to read past all the test files in builds that aren't --disable-tests would make interpreting the output a pretty specialized skill.
Depends on: 490223
Whiteboard: [automation]
Assignee: nobody → aki
Whiteboard: [automation] → [automation][triagefollowup]
Triage: Marked as triagefollowup since I won't have time in Q4 for this.
(In reply to Ben Hearsum [:bhearsum] from comment #4)
> Realistically, this probably won't happen soon.

Yeah, no kidding. :/

AFAICT, we're still blocked on bug 490223, if only partially (comment #5). Of course, a lot can change in 2 years. Is bug 490223 still valid?
Whiteboard: [automation][triagefollowup] → [automation]
It's not blocked in the sense of "can't do this until" - bug 490223 only blocks "make package-compare errors fatal" in that sense.

Without bug 490223 (and another one that's probably unfiled, to ignore the files that are shipped in omni.ja), only Standard8, nthomas, and I will ever take the time to learn how to ignore expected false positives and read the output.

With bug 490223, only Standard8, nthomas, and I will ever take the time to read the output.

Of course, if we apply a "more than three people must plan to look at the logged output" rule to decide whether to do something, we could drop 99% of the current build and test output, and pretty much drop running tests entirely :)
Not actively working on this.
Assignee: aki → nobody
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: → Release Engineering
You need to log in before you can comment on or make changes to this bug.