Closed Bug 1890753 Opened 2 years ago Closed 3 months ago

[meta] Let Release Management handle Merge Day without the need for Release Engineering to be involved

Categories

(Release Engineering :: Release Automation, enhancement, P2)

Product:
Release Engineering
Component:
Release Automation
Type:
enhancement

Tracking

(firefox-esr115 fixed, firefox-esr140 fixed, firefox149 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr115 --- fixed
firefox-esr140 --- fixed
firefox149 --- fixed

People

(Reporter: jlorenzo, Assigned: eijebong)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: meta)

Attachments

(5 files, 1 obsolete file)

[mozilla-releng/shipit] Bug 1890753 - Add support for merge automation to shipit (#1801)
50 bytes, text/x-github-pull-request
Details | Review
[mozilla-releng/scriptworker-scripts] Implement a mark-as-merged action for shipitscript (bug 1890753) (#1312)
64 bytes, text/x-github-pull-request
Details | Review
Bug 1890753 - Add a task to mark merge automation as complete in shipit. r=#releng-reviewers
48 bytes, text/x-phabricator-request
Details | Review
Bug 1890753 - Add a task to mark merge automation as complete in shipit.
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-esr140+
Details | Review
Bug 1890753 - Add a task to mark merge automation as complete in shipit.
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-esr115+
Details | Review

That's one of the items called out in bug 1782086 comment 0:

Allow sheriffs and/or relman the ability to trigger merge-automation actions

These days triggering the actions is not very complicated. By allowing sheriffs or relman permission to trigger them, we can guarantee the process can be started ASAP (since sheriffs have 100% coverage). This can help in the event both people on releaseduty are in North American timezones or have something come up and are afk.

In bug 1432655 and bug 1666321, we automated several steps. Yet, there are still some manual ones[1]. :gabriel started a conversation for the shipit part[2]. I'm filing this meta-bug because there are a few more things outside of shipit to fully hand off releaseduty to the Release Management team. On top of my head, I'm thinking of:

  • check the output of treescript is sane
  • emailing release-drivers@m.o when the merge is done
  • update the wiki (not sure how feasible it is today) - bug 1414278.

[1] https://github.com/mozilla-releng/relengdocs/blob/1ec975b6d8d86eaadfcfe17c24fdfd013c836ab9/how-to/releaseduty/merge-duty/merge_duty.rst
[2] https://github.com/mozilla-releng/shipit/issues/1418

There's also:

  • Releng makes a commit in ShipIt to bump the hard-coded version data
    This could be do-able with treescript + moving the version data to an structured file (maybe we can use products.yml?)
  • The click to update the product-details api/repository when we update the hard-coded version data
    Can we do this from a task after the one that updates the hard-coded data?
    This is more of a nice to have because RelMan can/does update product-details by clicking the button.
  • The mozilla-beta tree closure/re-opening
    TreeStatus has an API we might be able to leverage. It is moving to lando but the API will be compatible.
  • Releng manually fires a "ship-geckoview" hook after the mozilla-central tree version bump
Status: NEW → ASSIGNED
Severity: -- → N/A
Priority: -- → P2

(In reply to Gabriel Bustamante [:gabriel] from comment #1)

  • Releng manually fires a "ship-geckoview" hook after the mozilla-central tree version bump

This is actually no longer a thing since the firefox-android repo migration. It's included with the regular Nightly graph now. We should remove this from the documentation irrespective.

Mm, do sheriffs/relman have access to treestatus? iirc sheriffs do

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

(In reply to Gabriel Bustamante [:gabriel] from comment #1)

  • Releng manually fires a "ship-geckoview" hook after the mozilla-central tree version bump

This is actually no longer a thing since the firefox-android repo migration. It's included with the regular Nightly graph now. We should remove this from the documentation irrespective.

Thanks :RyanVM, that is a good thing!

(In reply to Gabriel Bustamante [:gabriel] from comment #3)

Mm, do sheriffs/relman have access to treestatus? iirc sheriffs do

I do, but that could be because I still have sheriffing bits on my LDAP :-)

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

(In reply to Gabriel Bustamante [:gabriel] from comment #3)

Mm, do sheriffs/relman have access to treestatus? iirc sheriffs do

I do, but that could be because I still have sheriffing bits on my LDAP :-)

Correct, treestatus access is granted to sheriffs + perf_sheriffs (https://hg.mozilla.org/ci/ci-configuration/file/f472b60a69081f8f05033890167c3271ccd0a060/grants.yml#l2282) and thunderbird-sheriff + thunderbird-releng (https://hg.mozilla.org/ci/ci-configuration/file/f472b60a69081f8f05033890167c3271ccd0a060/grants.yml#l2366).

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

(In reply to Gabriel Bustamante [:gabriel] from comment #1)

  • Releng manually fires a "ship-geckoview" hook after the mozilla-central tree version bump

This is actually no longer a thing since the firefox-android repo migration. It's included with the regular Nightly graph now. We should remove this from the documentation irrespective.

https://github.com/mozilla-releng/relengdocs/pull/264 updates the doc.

I'm exploring enhancements to the merge-automation - and I am thinking we can probably add a task to bump-central that makes a commit in shipit after the version bump on mozilla-central. This task would automatically make a commit in shipit to update the dates and nightly version.

The pushlog check bit seems straight forward, I think we can just check this endpoint.

Currently, we retrieve dates from the whattrainisitnow calendar, which we could potentially scrape, as it's formatted as a simple HTML table. Hopefully that wouldn't be too brittle. Does anyone know if whattrainisitnow offers an API? I couldn't find one.

Ah, to take ourselves out the the loop we might want to modify shipit to update this data without needing a deployment.

There's an release schedule API in whattrainisitnow with the data we get and manually hard-code: https://whattrainisitnow.com/api/release/schedule/?version=126

Depends on: 1895962
Depends on: 1916613
Depends on: 1921474
Depends on: 1921487
QA Contact: whole.grains

This is part of moving merge automation from an action task that has to
be run through treeherder to a fully supported shipit action.

Just like shipping uses mark-as-shipped to tell shipit that a release
graph is done, this creates a mark-as-merged that runs after the merge
automation graph is done. This means that we're not requesting a merge
automation ID as part of the merge automation input, which shipit will
provide when triggering said automation.

Assignee: gabriel → borivel
Pushed by borivel@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/7af5ba49a6ba https://hg.mozilla.org/integration/autoland/rev/511154f8d152 Add a task to mark merge automation as complete in shipit. r=releng-reviewers,taskgraph-reviewers,jcristau

This is part of moving merge automation from an action task that has to
be run through treeherder to a fully supported shipit action.

Just like shipping uses mark-as-shipped to tell shipit that a release
graph is done, this creates a mark-as-merged that runs after the merge
automation graph is done. This means that we're now requesting a merge
automation ID as part of the merge automation input, which shipit will
provide when triggering said automation.

Original Revision: https://phabricator.services.mozilla.com/D280400

Attachment #9543952 - Flags: approval-mozilla-beta?

firefox-beta Uplift Approval Request

  • User impact if declined: Merge automation through shipit requires this new task.
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: This just adds a task to merge automation iif a merge-automation-id arg is passed (which only shipit will pass). This doesn't change anything for "manually" ran merge automation which you could fall back to as a worst case scenarion
  • String changes made/needed: N/A
  • Is Android affected?: no

firefox-esr140 Uplift Approval Request

  • User impact if declined: Merge automation through shipit requires this new task.
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: This just adds a task to merge automation iif a merge-automation-id arg is passed (which only shipit will pass). This doesn't change anything for "manually" ran merge automation which you could fall back to as a worst case scenarion
  • String changes made/needed: N/A
  • Is Android affected?: no
Attachment #9543968 - Flags: approval-mozilla-esr140?

This is part of moving merge automation from an action task that has to
be run through treeherder to a fully supported shipit action.

Just like shipping uses mark-as-shipped to tell shipit that a release
graph is done, this creates a mark-as-merged that runs after the merge
automation graph is done. This means that we're now requesting a merge
automation ID as part of the merge automation input, which shipit will
provide when triggering said automation.

Original Revision: https://phabricator.services.mozilla.com/D280400

https://hg.mozilla.org/mozilla-central/rev/511154f8d152

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
status-firefox149: --- → fixed
Resolution: --- → FIXED
Attachment #9543968 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+
Attachment #9543952 - Attachment is obsolete: true
Attachment #9543952 - Flags: approval-mozilla-beta?
See Also: → 2018654

This is part of moving merge automation from an action task that has to
be run through treeherder to a fully supported shipit action.

Just like shipping uses mark-as-shipped to tell shipit that a release
graph is done, this creates a mark-as-merged that runs after the merge
automation graph is done. This means that we're now requesting a merge
automation ID as part of the merge automation input, which shipit will
provide when triggering said automation.

Original Revision: https://phabricator.services.mozilla.com/D280400

Attachment #9549396 - Flags: approval-mozilla-esr115?

firefox-esr115 Uplift Approval Request

  • User impact if declined: Can't run merge automation from shipit properly without this (it would never be marked as completed)
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: This is just adding an extra task to the merge automation task group. Worst case it fails and it's the same as it not existing.
  • String changes made/needed: N/A
  • Is Android affected?: no
Attachment #9549396 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: