Closed Bug 893409 Opened 9 years ago Closed 9 years ago
Stop generating nightly updates on mozilla-b2g18
_v1 _0 _1 when nothing has landed
Development on this branch has been closed for over a month now. We should remove it from TBPL. Once it is removed from there, I will also remove it from Treestatus. Alex/Lukas, are you OK with me doing this? If yes, we should probably also file a bug for stopping nightly builds on this branch, because those are still running daily AFAICT.
hi Ryan; It looks like you raised two points here: 1) Instead of deleting this, I believe this should be kept. My understanding is that this mozilla-b2g18_v1_0_1 branch is where we will need to land + evaluate any possible fixes for handoff to partners during the support life of v1.0.1. Therefore, I think we should keep these branches in place and mark the treestatus as closed/need approval, like we do for mozilla-release. 2) We expect (hope?) mozilla-b2g18_v1_0_1 to be quiet most of the time. During the day, we only build per-checkin, which is what people would want anyway. I fully agree that building nightly builds, when nothing has changed, is wasting compute time. Maybe we could just disable nightly builds? Use self-service for nightlies? If my understanding is correct, the only change in tbpl is to change the treestatus, and then this bug should be moved to RelEng:Automation. Did I miss anything?
mozilla-b2g18_v1_0_1 is already marked as closed in treestatus, so morphing this bug to be a releng bug for turning off nightly updates unless something has changed (or turning them off entirely in favour of manually triggering, if that is too much hassle).
Component: Tinderboxpushlog → Release Engineering: Automation (General)
Product: Webtools → mozilla.org
QA Contact: catlee
Summary: Remove the mozilla-b2g18_v1_0_1 branch from TBPL and Treestatus → Stop generating nightly updates on mozilla-b2g18_v1_0_1 when nothing has landed
Version: Trunk → other
(In reply to Ed Morley [:edmorley UTC+1] from comment #2) > mozilla-b2g18_v1_0_1 is already marked as closed in treestatus, so morphing > this bug to be a releng bug for turning off nightly updates unless something > has changed (or turning them off entirely in favour of manually triggering, > if that is too much hassle). I would have preferred that my bug not be morphed until I at least heard back from the release drivers on comment 0. My point is that B2G v1.0.1 is a closed branch (as you noted) and is not going to be reopened. Having it in Treestatus serves no purpose, because even on the off chance that something does need to land there, we can use CLOSED TREE to do so. I'll also note that this is exactly what we did with B2G v1.0.0 when development closed there. If we want to leave it on TBPL for that off chance, fine, but I would argue that adding it back would also be trivial in such a situation. IMO, it's still needlessly cluttering the list of trees.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #3) > I would have preferred that my bug not be morphed until I at least heard > back from the release drivers on comment 0. We really needed multiple bugs for this anyway, since it required changes to several tools. Given that we won't be deleting the repo, regardless of the TBPL outcome we'll need to turn off nightlies, so least we have a bug for that filed in the correct component now. If needs be we can re-file another for TBPL pending the response from lsblakk/akeybl :-)
(In reply to John O'Duinn [:joduinn] from comment #1) > 1) Instead of deleting this, I believe this should be kept. My understanding > is that this mozilla-b2g18_v1_0_1 branch is where we will need to land + > evaluate any possible fixes for handoff to partners during the support life > of v1.0.1. Therefore, I think we should keep these branches in place and > mark the treestatus as closed/need approval, like we do for mozilla-release. All deleting a branch from TBPL does is remove it from the list of trees in the UI. It's also trivial to reverse if we do find ourselves needing it for some reason. It has no impact on the underlying repository. And like I said above, removing it from Treestatus has no impact on our ability to push to it with CLOSED TREE in the commit message. > 2) We expect (hope?) mozilla-b2g18_v1_0_1 to be quiet most of the time. > During the day, we only build per-checkin, which is what people would want > anyway. I fully agree that building nightly builds, when nothing has > changed, is wasting compute time. Maybe we could just disable nightly > builds? Use self-service for nightlies? Yes, though I guess this bug is now about that now...
We may need to be able to create internal builds/updates in the future if there is a 1.0.1 chemspill. I don't have a strong opinion outside of anything that would impact that ability. It can be a one-off if necessary at that time.
Were we going to do this at some point? Lots of needless builds and tests that are still running every day.
Product: mozilla.org → Release Engineering
John, is it possible to get this on the RelEng radar? As noted throughout the bug, we are spinning redundant builds and tests on a daily basis for a branch that hasn't been updated in months and is unlikely to see any future updates. Ignoring the entire question of whether we should even be supporting this branch anymore, we all seem to agree at least that the daily builds and tests are a waste of resources.
Flags: needinfo?(lsblakk) → needinfo?(joduinn)
This is the patch which would build only on green changes, assuming we're good to go with this approach.
Comment on attachment 798339 [details] [diff] [review] [buildbot-configs] Build only green gecko changes LGTM. Or just stop doing builds there altogether?
Attachment #798339 - Flags: review+
Comment on attachment 798339 [details] [diff] [review] [buildbot-configs] Build only green gecko changes https://hg.mozilla.org/build/buildbot-configs/rev/dfd78324ab1f Earlier in this bug people expressed an interest in having builds available if we have to do a security fix. With this patch we'll get both dep and nightly builds if gecko changes (but not for other parts of the source).
Attachment #798339 - Flags: checked-in+
I think we're all done here.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
We're still generating nightlies, even when there have been no gecko changes.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hmm there aren't any recent ones now, maybe I just looked too soon after the reconfig.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.