1186678 - thunderbird per checkin tests should use mozilla- rev not comm- rev

Status: RESOLVED FIXED

(Release Engineering :: Applications: MozharnessCore, defect)

Description

[Jordan Lund (:jlund)]

e.g. http://ftp.mozilla.org/pub/mozilla.org/thunderbird/tinderbox-builds/comm-central-linux/1437525470/comm-central_ubuntu32_vm_test-xpcshell-bm04-tests1-linux32-build9.txt.gz

 argv: ['bash', '-c', u'python archiver_client.py mozharness --repo mozilla-central --rev 3903bf440cfd --destination scripts --debug']

the above 3903bf440cfd is a comm-central rev not mozilla-central

Comment 1

[Jordan Lund (:jlund)]

I ran out of time with this but essentially what's happening is:

before mh went in gecko tree, the logic was:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2015/07/2015-07-13-03-02-07-comm-central/comm-central_ubuntu32_vm_test-xpcshell-bm04-tests1-linux32-build8.txt.gz

and checked out mozharness from https://hg.mozilla.org/build/mozharness by looking at the rev pointed to by mozharness.json at the tip default rev of mozilla-central:
bash -c 'python repository_manifest.py --default-repo https://hg.mozilla.org/build/mozharness --default-revision production --manifest-url https://hg.mozilla.org/mozilla-central/raw-file/default/testing/mozharness/mozharness.json'

effectively, we were saying don't worry about which mozilla-central rev we poll for the https://hg.mozilla.org/build/mozharness rev to use, just use current 'default' rev.

So we could keep that same logic in the current scenario where mh is in tree by extending:
http://mxr.mozilla.org/build/source/buildbot-configs/mozilla/thunderbird_config.py#1070

with say:
branch['mozharness_archiver_revision'] = 'default'

and then add mozharness_archiver_revision as an arg to ScriptFactory like we did for mozharness_archiver_repo_path with the impl of:
if mozharness_archiver_revision:
     # use that
else:
   # use http://mxr.mozilla.org/build/source/buildbotcustom/process/factory.py#4877

though it be nice to not add another arg to ScriptFactory. Maybe there is a way we can know that the job is a TB job from within ScriptFactory already and condition off that.

will follow up tomorrow.

Comment 2

[Jordan Lund (:jlund)]

Attachment: 150722_bug_1186678_tb_tests_archiver_rev_fix.diff

this add the ability to define the archiver rev everywhere but it only effects tb tests atm. Normally we want it to be whatever the ff gecko revision is but tb is a special snowflake.

For pinning we just used 'production' mozharness so here we are maintaining that logic by using the current default tip of whatever moz_repo_path is.

dump_master diff for tests: http://people.mozilla.org/~jlund/tb_tests_archiver_rev_fix-dump_master.diff

dump master diff for builds was a noop

Comment 3

[Jordan Lund (:jlund)]

Attachment: 150723_bug_1186678_tb_tests_archiver_rev_fix-bbot-cfgs.diff

I knew I forgot something. That custom patch would be a noop if I didn't use it anywhere like this :)

dump_master in previous comment was using this patch too

Comment 4

[Jordan Lund (:jlund)]

Comment on attachment 8638041 [details] [diff] [review]
150723_bug_1186678_tb_tests_archiver_rev_fix-bbot-cfgs.diff

r=rail over irc

remote:   https://hg.mozilla.org/build/buildbot-configs/rev/f75ac37bef2c

Comment 5

[Jordan Lund (:jlund)]

Comment on attachment 8638024 [details] [diff] [review]
150722_bug_1186678_tb_tests_archiver_rev_fix.diff

remote:   https://hg.mozilla.org/build/buildbotcustom/rev/196963066a40

tyvm

Comment 6

[Jordan Lund (:jlund)]

In production: https://hg.mozilla.org/build/buildbot-configs/rev/f75ac37bef2c

Comment 7

[Jordan Lund (:jlund)]

In production: https://hg.mozilla.org/build/buildbotcustom/rev/196963066a40