Applying a tag before starting the build is "old school" and we don't need to wait for it to complete. Using dvcs (hg or git), the revision specified in the ship-it tool can be used to ensure consistent (same source) builds. Tagging has value for viewing repositories later, so should still be done, but need not block anything but post-release (just to ensure it does occur). Making this change would save approx 35 min per m-c based release build. Or so thought :rail, :catlee, & :hwine in #mozbuild one late evening.
A thing that we should consider as well is bumping things (versions, build IDs, etc) which is done as a part of tagging in our case.
My only reservation is that being able to retrigger things is much easier when you can punch in a tag name for revision rather than an actual revision. I don't think this is a blocker, though. It may be a non-trivial amount of work to make all of the different release jobs work with a rev instead of a tag, though.
(In reply to Ben Hearsum [:bhearsum] from comment #2) > It may be a non-trivial amount of work to make all of the different release > jobs work with a rev instead of a tag, though. If the estimate of ~35 / build is correct, I think it's probably worth the effort as that will be a substantial savings. Is this something that can be at least investigated in Q4?
The timeline runs something like this: t=0 started in ship-it +10m configs bumped, buildbot masters reconfiged (depends on master load a bit) +35m tagging done, en-US builds can start So this would be a nice time win, but per build so. And we should remember that we may bump versions in tagging, so bug 607392 may be a better goal.
With bug 607392 - split tagging into en-US and other, we saved ~20 minutes in build time and with build promotions we are not going to tag at all.