•jlund> Jordan Lund rail: I think the issue is that this was a little too early in the patch: https://hg.mozilla.org/mozilla-central/rev/f82cd0199ab7#l10.1 16:06:20 <•jlund> Jordan Lund I thought we just stopped building uni builds on aurora 16:06:28 this week 16:06:37 <•jlund> Jordan Lund to compound the confusion, I edited that patch locally on merge day. 16:09:54 I had to remove those lines because doing this: https://hg.mozilla.org/mozilla-central/rev/f82cd0199ab7#l10.16 16:10:12 duplicated this: https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/merge_day/aurora_to_beta.py?q=path%3Aaurora_to_beta&redirect_type=single#29 16:10:42 but really, I should have kept them in there but put them back to 'universal' ? •jlund> Jordan Lund so 1) fix uni osx l10n mozconfigs on beta 2) do a build 2 16:15:41 <•jlund> Jordan Lund fix == 16:18:11 https://hg.mozilla.org/releases/mozilla-beta/file/tip/browser/config/mozconfigs/macosx-universal/nightly#l17 16:18:12 https://hg.mozilla.org/releases/mozilla-beta/file/tip/browser/config/mozconfigs/macosx-universal/l10n-mozconfig#l6
for context, the migration scripts that live in mozharness, don't 'ride' the trains. They live in-tree but we consider central tip to be production. therefore, we run beta->release, aurora->beta, and central->aurora migration automation all with the same code base: ``` # checkout mozharness from the gecko tree using archiver wget http://hg.mozilla.org/build/tools/raw-file/default/buildfarm/utils/archiver_client.py python archiver_client.py mozharness --repo mozilla-central --rev default --debug python mozharness/scripts/merge_day/gecko_migration.py -c mozharness/configs/merge_day/aurora_to_beta.py python mozharness/scripts/merge_day/gecko_migration.py -c mozharness/configs/merge_day/central_to_aurora.py I think the confusion was that mshal thought we woul drun `python mozharness/scripts/merge_day/gecko_migration.py -c mozharness/configs/merge_day/aurora_to_beta.py` from mozilla-beta's mozharness tip so it was safe to change central's aurora_to_beta.py config now. mshal, do I have that right?  https://wiki.mozilla.org/ReleaseEngineering/Merge_Duty/Steps#Perform_mozilla-aurora_-.3E_mozilla-beta_and_mozilla-central_-.3E_mozilla-aurora_migrations
here is the actual post migration mozconfig patch
Attachment #8829906 - Flags: review?(rail)
just need one r+ but including mshal for fyi purposes. this fixes the migration scripts. explanation is within commit message inside the patch. I'm too used to doing that in mozreview but where I am right now, I'm blocked from using port 22 on mozreview server
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/2017142054f6 52.0b1 is busted due to migration bug, r=rail
https://hg.mozilla.org/integration/mozilla-inbound/rev/2017142054f661c550844289a7cc8de9592551f2 Bug 1333443 - 52.0b1 is busted due to migration bug, r=rail
I got this clarified over irc. confirmed mshal assumed this part of code rode the trains. It may be better to try and mirror the CI behaviour of mozharness so we don't run into this again.
Comment on attachment 8829908 [details] [diff] [review] 170124_bug_1333443_mozilla_central_migration_fix.patch Seems to make sense to me. We should probably get together at some point to figure out if our mozconfig layout & merge strategy still makes sense in the new world of things.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.