We don't have nightlies on esr38 (bug 1135024), and the S3 migration is going to deprecate firefox/tinderbox-builds/<foo>/latest. So we'll have nowhere to get a matching copy of xpcshell + libraries at http://mxr.mozilla.org/build/source/tools/scripts/periodic_file_updates/periodic_file_updates.sh#135 Rando-list of suggestions: * pin to some build, but tinderbox-builds will expire. Maybe a release build ? * turn nightlies back on, which incidentally gives some builds for regression hunting * invent a new buildapi endpoint to return urls, but it'll die after we move to TC * do TC uploads with indexing on esr38, so that we can query https://index.taskcluster.net/v1/task/buildbot.branches.mozilla-central.linux64 for the latest taskID, and then hit up https://queue.taskcluster.net/v1/task/E7pni5QCSxmzyCNnvNeHRg/artifacts mshal, how much would we need to uplift to get TC uploads on esr38 ?

It looks like esr38 doesn't use mozharness for builds, which is where the logic lives to do TC uploads for buildbot-based jobs. So I think getting esr38 to upload to TC would be non-trivial (either switching it to use mozharness, or adding TC-based uploading somewhere else specifically for esr38). It does look like esr38 has an in-tree mozharness that supports TC uploading, which should support the buildbot.* routes. The newer gecko.v2 routes wouldn't work without some additional patches uplifted, but I don't think that would be necessary here.

Hmm, yes; that was rather optimistic of me. https://bugzilla.mozilla.org/show_bug.cgi?id=1123965#c2 rather rules out the USE_MC option we have in the script, so perhaps we're forced into re-enabling nightlies, or hardcoding to a release. Do you have a preference coop ?

(In reply to Nick Thomas [:nthomas] from comment #2) > Hmm, yes; that was rather optimistic of me. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1123965#c2 rather rules out the > USE_MC option we have in the script, so perhaps we're forced into > re-enabling nightlies, or hardcoding to a release. Do you have a preference > coop ? I'm fine with re-enabling nightlies. Storage is free in s3, right? ;)

... but only when the code changes.

And leave updates off, so whimboo has nothing that needs testing.

Whee, and also on any b2g release branches where we do updates.

Comment on attachment 8676143 [details] [diff] [review] [buildbot-configs] Re-enable esr38 nightlies https://hg.mozilla.org/build/buildbot-configs/rev/c539ca0a6854

(In reply to Phil Ringnalda (:philor) from comment #6) > Whee, and also on any b2g release branches where we do updates. From using dxr to look at configs, it appears we have: blocklist: m-c, m-a, m-b, m-r, m-esr38, c-c, c-a, c-b, c-esr38 hsts+hpkp: m-c, m-a, m-esr38, m-b2g37_v2_2, m-b2g37_v2_2r So I haven't addressed blocklist on *-b & *-r, or hsts+hpkp on the two b2g branches. Wheee!

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

m-c is fine m-a is busted in hkpk, awaiting uplift of bug 1224968, but finds a build to run no problems m-b is fine, blocklist only and that doesn't require a nightly build m-r is fine, same as m-b m-esr38 is busted, but not because it can't find a nightly, bug 1231035 m-b2g37_v2_2 is busted, can't download a build to do hsts + pkpk, need to fix that here c-* are all fine, only doing blocklist and landed on all branches on Dec 5 (can't find the logs) So just need a solution for mozilla-b2g37_v2_2.

Why do we even run hsts/hkpk refreshes on v2.2 anyway ?

Going to take this, but only to disable hsts/hkpk updates on 2.2.

Comment on attachment 8704165 [details] [diff] [review] [buildbot-configs] Disable HSTS/HPKP updates on b2g 2.2 branches https://hg.mozilla.org/build/buildbot-configs/rev/65d3648d9b27

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