1183117 - make sure in-tree mozharness is used and works for releases

Status: RESOLVED FIXED

(Release Engineering :: Release Automation, defect)

Description

[[e-mail] (:bhearsum)]

We had a couple of issues with it for Firefox release automation, but that seems to be OK now. We haven't tested it at all for Fennec or Thunderbird though. I had a look at Fennec release logs and there's a few jobs that use it:
* builds, repacks, and bouncer submission are ScriptFactory based. I think they'll "just work":
http://ftp.mozilla.org/pub/mozilla.org/mobile/candidates/40.0b2-candidates/build1/logs/release-mozilla-beta-android-api-9_build-bm71-build1-build3.txt.gz
http://ftp.mozilla.org/pub/mozilla.org/mobile/candidates/40.0b2-candidates/build1/logs/release-mozilla-beta-android-api-9_repack_1-bm71-build1-build8.txt.gz
http://ftp.mozilla.org/pub/mozilla.org/mobile/candidates/40.0b2-candidates/build1/logs/release-mozilla-beta-fennec_bouncer_submitter-bm71-build1-build4.txt.gz
* source tagging references tags the external mozharness repo, but nothing else. that will go away in bug 1183106

As for Thunderbird, I see the following mozharness uses in 38.1.0 (logs here: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/candidates/38.1.0-candidates/build1/logs):
* en-US builds clone it, but don't appear to do anything with it. should probably stop cloning it
* bouncer submitter is scriptfactory based, should just work
* source tagging tags it, same as fennec

The one other difference for Thunderbird is that its "primary" repository is comm-central, so it may end looking for mozharness in that repo instead of gecko. We should probably decided if it should use the gecko repo mozharness, or use its own copy. I can see arguments both ways.

Comment 1

[Jordan Lund (:jlund)]

ben confirmed that the releases from the end of last week to today succeeded and used the Gecko copy of Mozharness everywhere.

The only last piece is test is TB but we spoke over irc and I pointed out that we already have a special case for that: http://hg.mozilla.org/build/buildbotcustom/file/default/process/release.py#l61

once we do a TB release, I believe we can close this bug

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

In logs like http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/40.0b6-candidates/build1/logs/release-mozilla-beta-linux64_build-bm71-build1-build11.txt.gz, was the fallback to using https://hg.m.o from temporary bustage ? I don't care too much, other than the few extra minutes added to the build.

Comment 3

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #2)
> In logs like
> http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/40.0b6-candidates/
> build1/logs/release-mozilla-beta-linux64_build-bm71-build1-build11.txt.gz,
> was the fallback to using https://hg.m.o from temporary bustage ? I don't
> care too much, other than the few extra minutes added to the build.

Comment 4

[Jordan Lund (:jlund)]

(In reply to Ben Hearsum [:bhearsum] from comment #3)
> (In reply to Nick Thomas [:nthomas] from comment #2)
> > In logs like
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/40.0b6-candidates/
> > build1/logs/release-mozilla-beta-linux64_build-bm71-build1-build11.txt.gz,
> > was the fallback to using https://hg.m.o from temporary bustage ? I don't
> > care too much, other than the few extra minutes added to the build.

yes, for now some builds will take an extra bit of time and fallback to hg.m.o. I'm hoping https://bugzil.la/1185507 will solve the timeouts

Comment 5

[[e-mail] (:bhearsum)]

Jordan, do you think there's anything left to do here? AFAICT, the latest Fennec (built on July 20th), Firefox (built on July 24th), and Thunderbird (built over this past weekend) all worked fine with in-tree Mozharness enable.d

Comment 6

[Jordan Lund (:jlund)]

\o/

I guess we can re-open or file a specific ticket if something comes up.