Add a buildstep to run |make package-compare|

RESOLVED WONTFIX

Status

Release Engineering
General
P4
normal
RESOLVED WONTFIX
9 years ago
5 years ago

People

(Reporter: philor, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [automation])

(Reporter)

Description

9 years ago
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.
(Reporter)

Updated

9 years ago
Depends on: 547599

Comment 1

9 years ago
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?
(Reporter)

Comment 3

9 years ago
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), http://build.mozillamessaging.com/buildbot/production/builders/Linux%20comm-central%20build/builds/2048/steps/shell_15/logs/stdio 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
(Reporter)

Comment 5

9 years ago
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

Updated

8 years ago
Whiteboard: [automation]

Updated

7 years ago
Assignee: nobody → aki

Updated

7 years ago
Whiteboard: [automation] → [automation][triagefollowup]

Comment 6

7 years ago
Triage: Marked as triagefollowup since I won't have time in Q4 for this.

Comment 7

7 years ago
(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]
(Reporter)

Comment 8

7 years ago
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 :)

Comment 9

6 years ago
Not actively working on this.
Assignee: aki → nobody
(Reporter)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.