893409 - Stop generating nightly updates on mozilla-b2g18_v1_0_1 when nothing has landed

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

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?

Comment 2

[Ed Morley [:emorley]]

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).

Comment 3

[Ryan VanderMeulen [:RyanVM]]

(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.

Comment 4

[Ed Morley [:emorley]]

(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 :-)

Comment 5

[Ryan VanderMeulen [:RyanVM]]

(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...

Comment 6

[Alex Keybl [:akeybl]]

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.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Attachment: 101.png

Were we going to do this at some point? Lots of needless builds and tests that are still running every day.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [buildbot-configs] Build only green gecko changes

This is the patch which would build only on green changes, assuming we're good to go with this approach.

Comment 10

[Chris AtLee [:catlee]]

Comment on attachment 798339 [details] [diff] [review]
[buildbot-configs] Build only green gecko changes

LGTM. Or just stop doing builds there altogether?

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

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).

Comment 12

[Chris AtLee [:catlee]]

I think we're all done here.

Comment 13

[Ed Morley [:emorley]]

We're still generating nightlies, even when there have been no gecko changes.

Comment 14

[Ed Morley [:emorley]]

Hmm there aren't any recent ones now, maybe I just looked too soon after the reconfig.