Closed Bug 1301782 Opened 8 years ago Closed 6 years ago

Tag RC releases


(Release Engineering :: Release Automation: Other, defect, P3)



(firefox62 fixed)

Tracking Status
firefox62 --- fixed


(Reporter: marco, Assigned: Callek)



(Whiteboard: [releaseduty])


(2 files)

I'm not sure what is the right component.

Currently, we're tagging the first RC (FIREFOX_RELEASE_49_BASE) both on mozilla-beta and mozilla-release. We're not tagging successive RCs, which makes it harder to know what landed between an RC and another.
Component: Other → Release Automation
QA Contact: mshal → rail
FTR, FIREFOX_RELEASE_49_BASE is not a RC1 tag, this is a merge day tag, not used in release automation.

To implement this:

1) change so it works without next_version set (required for bumping

2) Create a new task, similar to to handle tagging only

3) make sure to have it only for RCs (aka graph1) and run in parallel with publishing to balrog (after the human decision task)
I'm planning on working on some relpro-related tasks at the beginning of Q4 for a few days to fix some stuff and match with my releaseduty cycle as well. Am assigning this too to keep it in my records for that time.

If there's anyone else volunteering for it in the meantime, feel free to reassign.
Assignee: nobody → mtabara
Priority: -- → P2
See Also: → 1346465
Assignee: mtabara → nobody
Priority: P2 → P3
Whiteboard: [releaseduty]
This should be fixed for Fx59+. We don't have ESR52 RCs afaik.
Closed: 6 years ago
Resolution: --- → FIXED
I misspoke. We'll tag these once the final RC ships, but not for each RC revision. Reopening.
Resolution: FIXED → ---
:aki, offhand do you know if (and where) in taskgraph I can gather "which RC are we" in taskgraph? (rather than "which buildnumber we are"
Flags: needinfo?(aki)
Aiui, there is no marker for "which RC are we", only which build number. I believe the number of shipped RCs is equal to the number of build numbers with ship_rc phases run. We could index those, count them, and add 1 to determine which RC we are now, or we could keep track of this number somewhere else (ship-it v2?). We could also use previously existing RC tags to determine how many previous RCs there were on this version number, or pass this number down as another parameter. I'm guessing counting RC tags is probably the least amount of work among the above solutions.
Flags: needinfo?(aki)
Sylvestre, Marco.

So given the details in c#6 and with discussion amongst releng, my current plan is to implement "tag buildN early" as a seperate thing. So we'll have Firefox 65.0 build 1 tags, and build 2 tags and build3 tags, even if we only ship build 1 and 3 to rc...

Historically of course we've never had RC tags, and if we do RC tagging I'd like to try and do this in a cleaner way than I think I can devote time to right now.

Would this solve the use-cases you both are currently concerned about? if not can you try and articulate what use-cases it won't solve that you'd like to see solved?
Flags: needinfo?(sledru)
Flags: needinfo?(mcastelluccio)
Sounds great to me, thanks!
Flags: needinfo?(sledru)
WFM too.
Flags: needinfo?(mcastelluccio)
Comment on attachment 8986890 [details]
Bug 1301782 - Be explicit about what tags to create. r=aki

Aki Sasaki [:aki] has approved the revision.
Attachment #8986890 - Flags: review+
Comment on attachment 8986891 [details]
Bug 1301782 - Perform buildN tagging at promote phase. r=aki

Aki Sasaki [:aki] has approved the revision.
Attachment #8986891 - Flags: review+
Pushed by
Be explicit about what tags to create. r=aki
Perform buildN tagging at promote phase. r=aki
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Assignee: nobody → bugspam.Callek
Pushed by
Port bug 1301782 to TB [Be explicit about what tags to create]. rs=bustage-fix
Depends on: 1478883
You need to log in before you can comment on or make changes to this bug.