Remove duplicated mozbase modules from mozharness
Categories
(Release Engineering :: Applications: MozharnessCore, defect)
Tracking
(firefox68+ fixed)
People
(Reporter: ahal, Assigned: ahal)
References
Details
Attachments
(3 files, 1 obsolete file)
Comment 1•10 years ago
|
||
Comment 2•10 years ago
|
||
Comment 3•10 years ago
|
||
Comment 4•10 years ago
|
||
Assignee | ||
Comment 5•10 years ago
|
||
Comment 6•10 years ago
|
||
Comment 7•10 years ago
|
||
Assignee | ||
Comment 8•9 years ago
|
||
Assignee | ||
Comment 9•9 years ago
|
||
Comment 10•8 years ago
|
||
Assignee | ||
Comment 11•6 years ago
|
||
This makes sure that the mozharness scripts have access to all the packages in
the build system virtualenv (namely mozbase).
Assignee | ||
Comment 12•6 years ago
|
||
Depends on D22184
Comment 13•6 years ago
|
||
Andrew, please make sure to run a try build. I feel this is important given that the mozprocess code has been changed a lot in the last couple months, and which might cause regressions.
Assignee | ||
Comment 14•6 years ago
|
||
I'm not planning to push this through right now. These patches are up here to demonstrate how we can remove these extra mozbase modules from a technical standpoint.
There are tons of bustages caused by this patch, though so far they are all due to mozbase not being available in a variety of contexts where mozharness is. I might chip away at this over time, but if anyone wants to work on it, please feel free (just ping me first in case I have more changes locally).
Comment 15•6 years ago
|
||
I did a push to Try here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=46353bca84dc5264dac319d90c462d57cd4cf832
That's based on :ahal's patches, with a small fix for Windows. I don't see any mozharness/mozbase related failures there!
Comment 16•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 17•6 years ago
|
||
Comment 18•6 years ago
|
||
bugherder |
Comment 19•6 years ago
•
|
||
[Tracking Requested - why for this release]:
Backed out for l10n bustages e.g. https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=238357055&repo=autoland&lineNumber=364
backout: https://hg.mozilla.org/mozilla-central/rev/93075ec49df3982c26873b822d762bd3d8863fad
[task 2019-04-05T11:09:42.746Z] + python2.7 /builds/worker/workspace/build/src/testing/mozharness/scripts/desktop_l10n.py --clone-locales --list-locales --setup --repack --summary --locale=en-CA:default --locale=he:default --locale=it:default --locale=ja:default --config single_locale/firefox.py --config single_locale/linux32.py --config single_locale/tc_common.py --config single_locale/tc_linux_common.py --log-level=debug --scm-level=3 --work-dir=/builds/worker/workspace/build
[task 2019-04-05T11:09:48.503Z] Traceback (most recent call last):
[task 2019-04-05T11:09:48.503Z] File "/builds/worker/workspace/build/src/testing/mozharness/scripts/desktop_l10n.py", line 20, in <module>
[task 2019-04-05T11:09:48.503Z] from mozharness.base.script import BaseScript
[task 2019-04-05T11:09:48.503Z] File "/builds/worker/workspace/build/src/testing/mozharness/mozharness/base/script.py", line 55, in <module>
[task 2019-04-05T11:09:48.503Z] import mozinfo
[task 2019-04-05T11:09:48.503Z] ImportError: No module named mozinfo
Comment 20•6 years ago
|
||
FYI, the entry point here is taskcluster/scripts/builder/build-l10n.sh, which was still using python2.7 directly.
Assignee | ||
Comment 21•6 years ago
|
||
Thanks, should be a quick fix. This is one of those patches that affects the world and is really hard to catch everything on try, so was expecting a backout tbh.
Comment 22•6 years ago
|
||
Should we also try a beta simulation with this patch?
Assignee | ||
Comment 23•6 years ago
|
||
I don't think we need to, unless there are mozharness/taskcluster scripts that exist on beta but not central? I don't think this is something that needs to be uplifted either.
Comment 24•6 years ago
|
||
It's not about uplifts but checks that current m-c code would work on beta after the next merge day. If we land as is without running such a merge we could bust the weekly beta-sim jobs sheriffs most likely are still running.
Assignee | ||
Comment 25•6 years ago
•
|
||
Just waiting on try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1de59939ee5818c8b772402abb06b53d4a191057
I also ended adding the same $GECKO_PATH check to the test-macosx.sh
script, even though nothing using that script has a source checkout yet, just to future proof a bit.
Assignee | ||
Comment 26•6 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #24)
It's not about uplifts but checks that current m-c code would work on beta after the next merge day. If we land as is without running such a merge we could bust the weekly beta-sim jobs sheriffs most likely are still running.
I'm just not sure how this change could work on central but not beta, it's all self-contained in the same commit. But I'm not very familiar with the merge process so if someone wants to run a beta sim (I'm not sure how), feel free!
Assignee | ||
Comment 27•6 years ago
|
||
Ok, I think I ran one:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a0cdc4a1a2dde46dfb6ebb13cd846a3f32688462
But I realized this is running every task which is definitely overkill. I'll let the builds finish + a couple tests, then cancel the rest.
Updated•6 years ago
|
Comment 28•6 years ago
|
||
Comment 29•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/50495a5da9f6
https://hg.mozilla.org/mozilla-central/rev/c28c538fca0a
Comment 30•6 years ago
|
||
bugherder |
Description
•