Open Bug 1138544 Opened 10 years ago Updated 3 years ago

Unskip test_mozbuild_reading.py due to SpiderMonkey build failures

Categories

(Firefox Build System :: General, defect)

defect

Tracking

(Not tracked)

People

(Reporter: gps, Unassigned)

References

Details

Attachments

(1 file)

We are skipping a sub-test in config/tests/test_mozbuild_reading.py because of a failure in SpiderMonkey builds. We need to get this test unskipped, at least on non-SpiderMonkey builds.
Bug 1132771 landed with an unconditional skip of a test in test_mozbuild_reading.py because of an issue only impacting SpiderMonkey builds. First, config/tests are executed during SpiderMonkey builds. This is due to parts of config/ getting pulled into the objdir for SpiderMonkey builds. This is a bit awkward, but it's how the world works. The test in question was failing because MozbuildObject.from_environment() detects the top source and object directories, not SpiderMonkey directories. As a result, we were looking for config.status in a directory that didn't exist because SpiderMonkey builds aren't full builds. Patching MozbuildObject to do the right thing is out of scope because this behavior is a hornets nest not worth disturbing. This patch introduces a new class for config.status resolution failures. This probably should have been done months ago instead of raising a generic Exception. We modify the failing test to catch "incomplete" build environment failures and convert those to test skips. The test works on normal builds, but now skips on SpiderMonkey builds. This should be acceptable, as the test on the main build includes SpiderMonkey's files, so there is no loss in overall test coverage. We likely have other tests that fail without a config.status. We should consider adopting this pattern in more places. We may even want to consider a decorator for skipping tests if a build environment is not present.
Attachment #8571470 - Flags: review?(mh+mozilla)
Comment on attachment 8571470 [details] [diff] [review] Only skip moz.build reading tests if the environment is bad Review of attachment 8571470 [details] [diff] [review]: ----------------------------------------------------------------- (In reply to Gregory Szorc [:gps] from comment #2) > The test in question was failing because > MozbuildObject.from_environment() detects the top source and object > directories, not SpiderMonkey directories. As a result, we were looking > for config.status in a directory that didn't exist because SpiderMonkey > builds aren't full builds. Patching MozbuildObject to do the right thing > is out of scope because this behavior is a hornets nest not worth > disturbing. That is not true. Spidermonkey builds have config.status in their topobjdir. In fact, the test works fine when topobjdir is below topsrcdir, but only fails when it's in a non-child directory. The actual problem is that there is no mozinfo.json file for MozbuildObject to find the topsrcdir from that non-child objdir. Why are we not using config.status for that btw?
Attachment #8571470 - Flags: review?(mh+mozilla) → review-
The commit message was a bit misleading. I'll rewrite it. I think the reason we're searching for mozinfo.json instead of config.status is historical reasons. As I mentioned in the commit message, I'd rather not revisit this decision as part of this bug because it may break mach for certain scenarios. I'd encourage you to take another look at the patch.
Considering how many things are looking at mozinfo.json, I'd rather have js standalone builds emitting one. It's better to do this sooner rather than later because this is bound to bite us again in the future.
I'm not actively working on this.
Assignee: gps → nobody
Status: ASSIGNED → NEW
Product: Core → Firefox Build System
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: