iiuc we update the major version through automation too early. There is a period where we have 404s from when we bump bouncer and when we submit the first nightly with new major version rail> jlund: we may need to manually fix the bouncer entries after we start the new set of nightlies - apparently we update the links too early and they will be 404 for a few hours nthomas> it looks like the BncLoc and N jobs on https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=68151063d1c63ce445d67aa743a018d7f66fbb4d start at the same time 14:51:59 and the BncLoc (https://tools.taskcluster.net/groups/fVgJJIZuTN6iWeaC_EwyHQ/tasks/cpSSOOwPTkiAINepWMUj2w/details) only depends on the decision task 14:52:26 and then the nightlies got cancelled 14:53:00 <•jlund> Jordan Lund ah, so point Bnc tasks to dep on N jobs

aki> i think we have no deps for bouncer locations because we wanted to use the release beetmover dummy tasks:

More context of this in bug 1489405 comment 3. There's various solutions to this but I haven't addressed neither because: a) slipped my radar until last minute, oups b) long-term solutions is shippable builds which will add some of the end-of-promotion-phase tasks to their nightlies neighbors. Once that happens, we can chain the bouncer-locations job to that and problem solved. Since I'm releaseduty this cycle, I'll have some slight more time to look into implementing some solutions to this. Johan mentioned a good one too in but 1489405 comment 7. Closing this as dupe of bug 1489405 since I'm already tracking that there.

To close loop here for now - thanks Rail and Aki for taking care of this while I was afk. They switched those to 65 manually until the builds were made available by beetmover. Automation bouncer-location for subsequent set of nightlies fixed this and turned all the locations mentioned here (formerly https://github.com/mozilla-releng/releasewarrior-2.0/commit/c9f1f474273bc36e51901251981a6f77bd5719be#diff-e235d9d2d06299a092b678b115f40079) back to 66. We're all good for this cycle.