1563530 - Be smarter about adding candidate trees to artifacts.py

Status: RESOLVED FIXED

(Firefox Build System :: General, task)

Description

[Ryan VanderMeulen [:RyanVM]]

Over in bug 1563038, we added a few more trees to the candidate list for artifact builds so that developers pushing to Try from those repos won't hit otherwise-avoidable bustage and delays iterating on time-sensitive patches.

The drawback is that there is a non-zero overhead for all artifact builds for each tree added, which means that developers pushing to Try now will incur a bit of a slowdown in the common case of developing on Trunk so that Beta and Release also work when needed. Also, we had to manually add the ESR repos to the list for their respective uplifts, which isn't something we're likely to remember to do at the start of each of those cycles.

Can we maybe cut this list down on Trunk to just m-c and the 2 integration branches and then have the various release branches get added to the list as a given release rides the trains? That would seem to give us the best of both worlds from an overhead and ergonomics standpoint, albeit at the expense of adding a bit more in-tree hacking on merge day (which I understand we're trying to reduce).

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Bug 1736565 improved this, but we still fundamentally have the issue of needing to remember to add every new ESR branch we create once a year.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

The more I think about it, the more I think that we may just need to update RelEng documentation somewhere for the start of a new ESR cycle and call it a day here. I think bug 1736565 accomplished the rest that this was setting out to fix. Mihai, is that something you can help facilitate?

Comment 3

[Mike Hommey [:glandium]]

I wonder if there's a reason not to use mozilla-unified's pushlog... it would contain all branches.

Comment 4

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #2)

The more I think about it, the more I think that we may just need to update RelEng documentation somewhere for the start of a new ESR cycle and call it a day here. I think bug 1736565 accomplished the rest that this was setting out to fix. Mihai, is that something you can help facilitate?

Added to my queue for releduty post-mortem this week. Keeping the NI until we have the docs landed.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Looks like Mihai isn't going to do it. Maybe Julien could help?

Comment 6

[Julien Cristau [:jcristau]]

Our "start a new ESR" process, AFAIK, includes "grep for esr<old> mentions in tree and adjust to the new one", which catches this.

Re comment 3, mozilla-unified excludes non-default branches which can happen on beta/release/esr.

Comment 7

[Julien Cristau [:jcristau]]

Attachment: releng docs PR

Comment 8

[Julien Cristau [:jcristau]]

https://docs.mozilla-releng.net/en/latest/procedures/release-duty/merge-duty/merge_new_esr_branch.html#internal-changes updated