Closed Bug 1000217 Opened 6 years ago Closed 5 years ago

disable uploading to update.boot2gecko.org for everything

Categories

(Release Engineering :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

References

Details

Attachments

(1 file)

After we switch them to aus4.m.o
Nick noted yesterday that there's cleanup cronjobs that we need to turn off after we do this, too. Otherwise the updates that switch people to Balrog might go away.
Summary: disable flame update uploading to update.boot2gecko.org → disable uploading to update.boot2gecko.org for mozilla-central/1.4
No longer blocks: 918068
Depends on: 918068
We'll want to do this for Aurora, too. Going to wait until 1.4 is confirmed to be working after landing today before doing this.
Summary: disable uploading to update.boot2gecko.org for mozilla-central/1.4 → disable uploading to update.boot2gecko.org for mozilla-central/mozilla-aurora/1.4
We can't do this until update.boot2geck.org is dead, because the configs for 2.1/2.0/1.4 are shared with 1.3, which still uses update.boot2gecko.org. However, this does mean that we can kill a bunch of dead code/config settings when we do this:
* The make-update-xml and upload-updates steps in https://hg.mozilla.org/build/mozharness/file/a9b8af62cf14/scripts/b2g_build.py. Maybe some code in make-updates.
* The actions and *update* from the following configs:
** https://hg.mozilla.org/build/mozharness/file/a9b8af62cf14/configs/b2g/releng-fota-updates.py
** https://hg.mozilla.org/build/mozharness/file/a9b8af62cf14/configs/b2g/releng-private-updates.py

I think that's it...
Looks like it'll be awhile before we can do this still. We're waiting for the 1.3/1.3t branches to go away, and we haven't even shipped Tarako yet. I assume we have to support that branch for awhile after shipping, so I assume this could be waiting as long as Q1 2015.
See Also: → 1079256
Blocks: 1079256
No longer depends on: 1079256
Summary: disable uploading to update.boot2gecko.org for mozilla-central/mozilla-aurora/1.4 → disable uploading to update.boot2gecko.org for everything
Need to test this first, seems a tad risky.
Comment on attachment 8545444 [details] [diff] [review]
disable uploads, kill dead code

So...I don't actually know any way decent way of testing this. Given that these nightlies are only used by QE, I think I'm OK with just eyeballing it, and watching for failures when the next set of nightlies runs. Does that seem reasonable, or should I go to the trouble of setting up a staging master et. al to test this?
Attachment #8545444 - Flags: review?(catlee)
Attachment #8545444 - Flags: review?(catlee) → review+
Comment on attachment 8545444 [details] [diff] [review]
disable uploads, kill dead code

Landed on default.
Attachment #8545444 - Flags: checked-in+
I think this worked. The latest b2g nightlies are fine, and I don't see any new files in the last 24h:
[ec2-user@ip-10-39-70-110 data]$ find . -mtime -1
./update-channels/nexus-4/2.0.0/nightly
./update-channels/nexus-4/2.1.0/nightly
./update-channels/nexus-4/2.2.0/nightly
./update-channels/nexus-4/1.4.0/nightly
./update-channels/helix/2.0.0/nightly
./update-channels/helix/2.1.0/nightly
./update-channels/helix/2.2.0/nightly
./update-channels/helix/1.4.0/nightly
./update-channels/hamachi/2.0.0/nightly
./update-channels/hamachi/2.1.0/nightly
./update-channels/hamachi/2.2.0/nightly
./update-channels/hamachi/1.4.0/nightly
./update-channels/flame-kk/2.0.0/nightly
./update-channels/flame-kk/2.1.0/nightly
./update-channels/flame-kk/2.2.0/nightly
./update-channels/dolphin/2.2.0/nightly
./update-channels/dolphin/1.4.0/nightly
./update-channels/flame/1.4.0/nightly
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.