Status

defect
P3
normal
RESOLVED FIXED
3 years ago
Last year

People

(Reporter: marco, Assigned: Callek)

Tracking

unspecified
Dependency tree / graph

Firefox Tracking Flags

(firefox62 fixed)

Details

(Whiteboard: [releaseduty])

Attachments

(2 attachments)

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 https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/release/postrelease_version_bump.py so it works without next_version set (required for bumping https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/release/postrelease_version_bump.py#118)

2) Create a new task, similar to https://github.com/mozilla/releasetasks/blob/master/releasetasks/templates/firefox/version_bump.yml.tmpl 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
Assignee: mtabara → nobody
Priority: P2 → P3
Whiteboard: [releaseduty]
This should be fixed for Fx59+. We don't have ESR52 RCs afaik.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
I misspoke. We'll tag these once the final RC ships, but not for each RC revision. Reopening.
Status: RESOLVED → REOPENED
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.

https://phabricator.services.mozilla.com/D1757
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.

https://phabricator.services.mozilla.com/D1758
Attachment #8986891 - Flags: review+
Pushed by Callek@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/eb64af8f8cec
Be explicit about what tags to create. r=aki
https://hg.mozilla.org/integration/mozilla-inbound/rev/5abb841c6ec2
Perform buildN tagging at promote phase. r=aki
https://hg.mozilla.org/mozilla-central/rev/eb64af8f8cec
https://hg.mozilla.org/mozilla-central/rev/5abb841c6ec2
Status: REOPENED → RESOLVED
Closed: 2 years agoLast year
Resolution: --- → FIXED
Assignee: nobody → bugspam.Callek
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/7b770efcdda0
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.