comm-esr31 does wasteful things while cloning mozilla-esr31



5 years ago
4 years ago


(Reporter: nthomas, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [kanban:engops:] )



5 years ago
Saw some strangeness in the en-US 31.1.0 build2. is called like this:

'python' 'c:/builds/moz2_slave/tb-rel-c-esr31-w32_bld-0000000/build/build/pymake/' '-f' '' 'build' u'MOZ_BUILD_DATE=20140828165811'

It clones mozilla-esr31 and ldap-sdks, and updates both to the appropriate tag. Then this runs

c:\builds\moz2_slave\tb-rel-c-esr31-w32_bld-0000000\build\$ python c:/builds/moz2_slave/tb-rel-c-esr31-w32_bld-0000000/build/ checkout --hg-options='--time' --hgtool=../tools/buildfarm/utils/ --hgtool1=../scripts/buildfarm/utils/ --skip-chatzilla --skip-comm --skip-inspector --skip-venkman --tinderbox-print

It wants to try to use hg share and says

hg path isn't correct ( should be; clobbering
Using _rmtree_windows ...
Updating shared repo

Then it goes on get a working copy, update to tag, and to compile. We're probably wasting 30 mins or more on this.
Ok, this is a side-effect of two things. There's a changeset I'm generally landing each cycle that stops l10n using hgtool (because of previous issues with hgtool & l10n):

Due to the way our clone and pull system works, we currently end up pulling twice.

Additionally, there's code in to strip the trailing slash for hgtool builds:

There's probably a few potential solutions (or combinations) here:

- Find a way to not do the pull cycle twice
- Always drop the trailing slash, not just for hgtool
- Find out what's going on with L10n builds, and why hgtool doesn't work.

Tentatively tagging myself with looking at this in the next release cycle.
Assignee: nobody → standard8


4 years ago
Whiteboard: [kanban:engops:]


4 years ago
Whiteboard: [kanban:engops:] → [kanban:engops:]


4 years ago
Whiteboard: [kanban:engops:] → [kanban:engops:]
Unfortunately, I'm unlikely to find time to work on this in the short term.

cc'ing some folks who might be interested - this would be a big win for build time and would probably reduce the time for release builds a bit.

Most of the details are in comment 1.
Assignee: standard8 → nobody
Note: this also causes us to need to transplant:

for every beta cycle.
Bug 757798 is the L10n issue.
Depends on: 757798
We seem to be using hgtool for l10n builds on both beta and central now and the "hg path isn't correct" message does not show during repacks. Therefore I think we can close this issue.
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.