Closed
Bug 682898
Opened 14 years ago
Closed 14 years ago
Create a test to ensure comm-central and mozilla-central configuration harness is in sync
Categories
(Thunderbird :: Build Config, defect)
Thunderbird
Build Config
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 9.0
People
(Reporter: gozer, Assigned: Callek)
Details
Attachments
(1 file)
1.49 KB,
patch
|
standard8
:
review+
|
Details | Diff | Splinter Review |
Bug 656049 copied some of mozilla-central's configuration harness into comm-central, and they will diverge over time.
Create a make check test that verifies that the files are identical and warns otherwise, so we can more easily keep them in sync.
Assignee | ||
Comment 1•14 years ago
|
||
Ok, this patch does a few things:
#1 I decided to reuse the m-c test python program. We are not running it prior to a normal build, so we can rely on it being present.
#2 I did *not* set it to run in client.mk as m-c currently (since that was done to fail-early for them) since we can *only* expect orange and not blocking people, since m-c can change from under us.
#3 the exceptions file only applies to "current" dir, and only files that are in _copy_ (c-c) and known to be absent or different from files in _source_ (m-c) need to be listed.
#4 flight.mk needs to be different, since we push mozilla/ to many paths there, and we add mozmill stuff to it.
Running this locally passes.
Attachment #556757 -
Flags: review?(mbanner)
Assignee | ||
Comment 2•14 years ago
|
||
Comment on attachment 556757 [details] [diff] [review]
Test It
alt review from KaiRo, as I'd rather not let a test for checked-in-code languish, and Mark is taking a while.
Attachment #556757 -
Flags: review?(kairo)
Comment 3•14 years ago
|
||
Would we want to do something like bug 677577 instead, so that we can catch this at an earlier stage of the build cycle, or do we just want our tests/code to run anyway, and just flag the fact these files are different?
Assignee | ||
Comment 4•14 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #3)
> Would we want to do something like bug 677577 instead, so that we can catch
> this at an earlier stage of the build cycle, or do we just want our
> tests/code to run anyway, and just flag the fact these files are different?
IMO, no. I didn't want us to fail early for this code. The chances of the m-c copies changing in an incompat way are slim. I felt it wasn't worth failing early on this, once this trips we can just land the fix.
The m-c side fails early because everything it is testing is in the same repo. So if it fails it was due to the checkin where it failed on, in our case, it would be do to a m-c checkin.
Comment 5•14 years ago
|
||
Comment on attachment 556757 [details] [diff] [review]
Test It
>+check::
>+ @$(PYTHON) $(TOPSRCDIR)/mozilla/js/src/config/check-sync-dirs.py \
>+ $(TOPSRCDIR)/build $(TOPSRCDIR)/mozilla/build
>+
You should be using $(topsrcdir) as per the rest of the file - otherwise this will fail on Mac and probably Linux as well.
r=me with that fixed.
Attachment #556757 -
Flags: review?(mbanner)
Attachment #556757 -
Flags: review?(kairo)
Attachment #556757 -
Flags: review+
Assignee | ||
Comment 6•14 years ago
|
||
http://hg.mozilla.org/comm-central/rev/d95685da754f with nit addressed
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•14 years ago
|
Target Milestone: --- → Thunderbird 9.0
You need to log in
before you can comment on or make changes to this bug.
Description
•