202
edits
Compatibility/System Addon/Release Process: Difference between revisions
Compatibility/System Addon/Release Process (view source)
Revision as of 12:25, 18 April 2023
, 18 April 2023Add notes on how to uplift something in the firefox-android repo
m (DenSchub moved page Compatibility/Interventions Releases to Compatibility/System Addon/Release Process: This is about the WebCompat System Addon, and thus should be in the right namespace. Makes it easier to find.) |
(Add notes on how to uplift something in the firefox-android repo) |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
__TOC__ | __TOC__ | ||
Generally speaking, new interventions are landed in <tt>mozilla-central</tt> close to the start of each cycle's soft freeze period, and then ride the trains to Release. By essentially skipping the Nightly cycle, we speed up the process a bit, but we get some stability testing in Beta before the interventions are available to all users. | |||
In cases that are more urgent, we can speed up the process by | |||
* uplifting interventions into Beta at any time during the cycle, | |||
* uplifting the interventions into Release to be shipped with the next dot-release, | |||
* shipping an interventions add-on update out-of-band. | |||
' | It is up to each release's Interventions Owner to decide if a WebCompat bug is important enough to warrant a fast process. | ||
== | == The normal process: Letting interventions ride the train == | ||
For low-priority interventions, the simplest way to ship is to land them in the tree and have them ride the trains like any code change. | |||
# Build and test the interventions as usual. Submit a Pull Request to the <tt>mozilla-extensions/webcompat</tt> GitHub repository that does include new interventions, but do not include a version number bump yet. | |||
# Bump the version number in <tt>manifest.json</tt> in your local clone of the repo, but do not commit the change yet. | |||
# Export your changed sources into your <tt>mozilla-central</tt> checkout. Check the [https://github.com/mozilla-extensions/webcompat-addon#readme addon's <tt>README.md</tt>] for instructions on how to use the tooling. | |||
# Make sure <tt>./mach lint browser/extensions/webcompat</tt> passes. Since the on-GitHub lints are not exactly the same (primarily, <tt>eslint</tt> is missing), it's a good idea to run that every time. | |||
# Submit the patch to Phabricator. You do not ''need'' to manually specify a reviewer: the <tt>webcompat-reviewers</tt> group will be added automatically, sending a notification to everyone in the team. | |||
# Land the patch. Wait until the patch got merged into <tt>mozilla-central</tt> to make sure it doesn't get backed out immediately. | |||
# Export the same sources into your local checkout of <tt>android-components</tt>. There is tooling to help you with that as well, see [https://github.com/mozilla-extensions/webcompat-addon#readme addon's <tt>README.md</tt>]. [https://github.com/mozilla-mobile/android-components/pull/11938 Example Pull Request]. To make it easier to keep track of, attach a link to the pull request to the corresponding bug on Bugzilla. If you don't know someone who can review your patch, ask in <tt>#fenix-team</tt> on Slack. | |||
# When the patch is merged, you can commit the version number change in the <tt>webcompat-addon</tt> repository. Make sure to run <tt>npm run autoformat</tt> before commiting, as that will apply your version number change to <tt>package.json</tt> and <tt>package-lock.json</tt> as well. | |||
# Tag the version with <tt>git tag -a v100.0.0 -m 'v100.0.0'</tt>, and push both your version-bump-commit, and the new tag, to GitHub with <tt>git push origin main v100.0.0</tt> | |||
# Make sure that for any intervention you added, you set the <tt>sitepatch-applied</tt> label GitHub or the <tt><nowiki> | |||
[webcompat:sitepatch-applied]</nowiki></tt> whiteboard flag on Bugzilla. Likewise, remove those labels for all interventions you removed. | |||
== | == Uplifting new interventions into Beta == | ||
=== mozilla-central === | |||
For interventions that are a bit more urgent, you can skip one release cycle and uplift your intervention(s) into Beta. However, '''do not just request beta uplift''' for the patch you submitted to <tt>mozilla-central</tt>: | |||
* It is possible that your patch was not the only change to the addon since the Beta branch got merged. This would cause conflicts, because your new patch won't cleanly apply to Beta. | |||
* Version numbers won't make sense: If you're uplifting a patch for the addon version <tt>101.0.0</tt> into Beta 100, you might make version numbers more confusing, and you also will make rolling out of-of-band updates a bit more complicated. | |||
* It generally is a good idea to limit your Beta uplift to only the important/urgent things. It might not be a wise idea to uplift everything, which might include logic changes, SmartBlock Fixes, and other changes into beta. Keep the risk as low as possible. | |||
Instead, we generally build a separate patch just for Beta. | |||
# Follow the "normal process", and get your interventions landed in <tt>mozilla-central</tt>. Wait for the next Nightly build, and make sure your interventions work as you expect. | |||
# In your local <tt>mozilla-central</tt> checkout, switch to the <tt>mozilla-beta</tt> branch/bookmark. If you've never done this before, check [https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html the documentation explaining how to work with the <tt>mozilla-unified</tt> repository]. | |||
# Apply the relevant changes to the Firefox sources. | |||
#* If your patch is simple, you can apply the changes directly to your <tt>mozilla-beta</tt> tree. | |||
#* If your changes are more complicated, it might be a good idea to use the export tooling in our GitHub repo. You can <tt>git checkout</tt> the tag corresponding to the version currently shipping in Beta, and then <tt>git cherry-pick</tt> individual patches from <tt>main</tt> into your temporary branch. There is no need to publish/merge that branch upstream, as your beta rollout should never include any interventions that aren't also in the <tt>main</tt> branch anyway. | |||
# Publish the beta patch to Phabricator and have a webcompat-reviewer rubberstamp the patch. It is a good idea to add a clear indication into the commit message saying that this patch is meant for the Beta branch. <tt>Bug 1234567 - Beta - Uplift v101 Interventions into v100 Beta.</tt> is an example. | |||
# Set the <tt>approval-mozilla-beta?</tt> request flag, and explain in the comment why you think this patch should be uplifted to Beta. | |||
A | A release manager will see your request. If your request is approved, the release managers will push your patch. You do not need to land it, or do anything else! | ||
=== | === firefox-android === | ||
For Android, the process is slightly different. After your Pull Request has been merged (and, ideally, tested), leave a comment in the Pull Request to tell the Mergify bot to create a backport PR (replace the version number with the target version number): | |||
<tt>@mergify backport releases_v113</tt> | |||
The bot will create a new PR and attach that PR to the original Bugzilla bug. You don't have to work on the GitHub PR, but you have to set the <tt>approval-mozilla-beta?</tt> flag on Bugzilla for the backport PR. After that, Release Management will proceed as usual. | |||
== Uplifting new interventions into Release == | |||
If you want your interventions to be available to users very quickly, you can uplift them into <tt>mozilla-release</tt> and have it shipped in the next dot-release. | |||
# There is no fixed schedule for dot-releases, but you can reach out to the [[Release_Management/Release_owners|Release Owner]] and ask if a dot release is planned, and when it will be shipping. If there is a dot release coming up that fits your needs, let them know that you intend to ship WebCompat interventions in that release. | |||
# Get your interventions into <tt>mozilla-central</tt> first, using the "normal process" explained above. Make sure it works! | |||
# Then, you can follow the "uplifting into Beta" steps. The steps for Beta and Release are exactly the same, except that you're using a different branch/bookmark: <tt>mozilla-release</tt> instead of <tt>mozilla-beta</tt>. | |||
# You can request uplift for Beta and Release at the same time, but since these are two different patches, you have to request both uplifts separately in two comments. | |||
== | == Shipping interventions with an out-of-band System Addon Update == | ||
=== Prerequisites === | |||
= | Before you can do any of the work outlined here, you need to make sure that your Mozilla LDAP account is a member of the <tt>vpn_cloudops_shipit</tt> and <tt>xpi_system_build</tt> groups. If you are not sure, [https://firefox-ci-tc.services.mozilla.com/profile check your LDAP profile here (Mozilla-internal)]. If one or both groups are missing, file a bug similar to [https://bugzilla.mozilla.org/show_bug.cgi?id=1683143 bug 1683143 (Mozilla-internal)]. | ||
You also need to be able to connect to the Mozilla Corporate VPN to use ShipIt. See [https://mana.mozilla.org/wiki/display/SD/VPN this guide (Mozilla-internal)] if you're currently not set up for that. | |||
=== Preparations === | |||
Since all changes that are about to be shipped need QA verification, we try to limit the changes to only the things we absolutely need to ship to Release users. As opposed to the other workflows, the primary work for rolling out an update happens on GitHub. Syncing the code back into <tt>mozilla-central</tt> is a step to be done after the update has been kicked off. | |||
The addon's GitHub repository has a <tt>release-hotfix</tt> branch. This branch does not automatically track what's shipping in Firefox Release, and we do not have a process for updating the branch each release cycle. Instead, before doing any work, you have to update the hotfix branch to match the code shipping to Firefox Release. To update that branch: | |||
# Switch your local checkout of the addon sources to the <tt>release-hotfix</tt> branch. Make sure to <tt>git pull</tt>, in case your local checkout is outdated. | |||
# In your <tt>mozilla-central</tt> clone, check out the <tt>mozilla-release</tt> branch/bookmark. | |||
# Check which commit touched the landed addon sources last. If you're using Git for your <tt>mozilla-central</tt>, you can use <tt>git log browser/extensions/webcompat/</tt>. With <tt>git show [the last commit's hash]</tt> check which version number the sources were bumped to. | |||
#* If the version number has a [https://github.com/mozilla-extensions/webcompat-addon/tags corresponding tag in the addon's repository], you can merge that tag into the <tt>release-hotfix</tt> branch with <tt>git merge --ff-only v100.2.1</tt>. | |||
#* If the version number does not have a tag, check [https://github.com/mozilla-extensions/webcompat-addon/commits/main the addon's commit history], and find the commit hash of the backporting commit of that change. Merge the sources up until that commit into the <tt>release-hotfix</tt> branch with <tt>git merge --ff-only [commit hash]</tt>. | |||
#* If the change has not been backported, or you cannot merge a tag/commit cleanly without conflicts, press the "emergency meeting" button in the team. Something has gone really wrong. | |||
If you're done, running the "export into mozilla-central" command should result in no actual changes to your <tt>mozilla-release</tt> checkout. If there are any changes, you merged the wrong tag or commit. Make sure the export is "clean" before proceeding. Otherwise, you might end up accidentally shipping the wrong/additional changes to release. | |||
If the export is not resulting in any changes, <tt>git push</tt> the updated <tt>release-hotfix</tt> branch to GitHub. | |||
Make sure the [[Release Management/Release owners|the Release Manager owning the target Firefox version]] is aware of your intentions to ship an update. Also, have a chat with our Softvision WebCompat team member so they can schedule a bit of time testing your release. | |||
== | === Preparing your patch === | ||
# With the addon's <tt>release-hotfix</tt> branch as a base, switch to a new branch for your changes. | |||
# Write and test your interventions as usual. Commit them as usual as well. | |||
# In a separate commit in your branch, bump the version number by a patch-level increase, for example from <tt>100.1.0</tt> to <tt>100.1.1</tt>. Commit that change as well. Make sure that the commit bumping the version number is last in your branch, if it isn't, use <tt>git rebase -i release-hotfix</tt> to reorder the commits. | |||
# Open a PR for your changes. GitHub should figure out that the base branch is <tt>release-hotfix</tt>, but if it doesn't, make sure to set that correctly before submitting the PR. | |||
# Have another member of the team review your PR. | |||
# Test your changes once again, for good measure. Then, merge your PR into the <tt>release-hotfix</tt> branch. | |||
=== Kicking off the build process === | |||
For testing, we do not use the build artifacts for each commit on GitHub, and instead start a new release on ShipIt. The reason we do not use the dep-signed XPI from a commit's job is consistency: When you start a release on ShipIt, it builds an <tt>.xpi</tt> for you to test. In the end, once all testing and QA'ing is done, the same <tt>.xpi</tt> will be shipped to our users, just with a different signature. Essentially, this means we are QA'ing "the same binary" that will be shipped, reducing the chance of weird build-specific glitches. | |||
# Follow the [https://github.com/mozilla-extensions/xpi-manifest/blob/main/docs/releasing-a-xpi.md#starting-the-build-phase "Starting the build phase" steps here]. | |||
#* The list of available XPIs has two WebCompat entires: <tt>webcompat</tt> and <tt>webcompat-release-hotfix</tt>. Pick <tt>webcompat-release-hotfix</tt>, as the other one will build and release the <tt>main</tt> branch. | |||
#* When selecting the revision, double-check that the last revision is correct. This should be a merge commit merging your PR. | |||
# The "Build" link in ShipIt links to taskcluster. You'll see a <tt>dep-signing-webcompat-release-hotfix</tt> task. When the task is completed, the artifacts for that task includes a <tt>webcompat.xpi</tt>. Copy the URL to that. | |||
# Ask our QA friends to test that dep-signed XPI. | |||
#* A template for a QA request can be found [https://bugzilla.mozilla.org/show_bug.cgi?id=1767811#c5 here]. | |||
#* The link to the XPI is the one you copied earlier. | |||
#* Links to current unbranded builds can be found [[Add-ons/Extension_Signing#Unbranded_Builds|here]]. | |||
# After QA is done testing the dep-signed XPI, you need two System Addon admins (or one SAO admin and a Release Engineer as backup) to sign off. Use the <tt>#addons-pipeline</tt> channel on Slack to ask. To make everyone's work easy, provide a link to the bug and a link to the changes (for example a link to the merged GitHub PR). | |||
# When you have received the necessary signoffs, the Ship graph will be triggered, which will sign the .xpi with a Release certificate. Ask a Release Engineer (if in doubt, use the same Slack channel) to get the release-signed .xpi into Balrog's <tt>release-sysaddon</tt> channel. They'll need to know which Firefox version(s) you're targeting with your update, which usually is all minor versions of a given release, i.e. <tt>100.*</tt>. | |||
# When a release engineer created and deployed the <tt>release-sysaddon</tt> rules, ask our QA people to run a second round of testing. | |||
#* A template with all relevant explanations can be found [https://bugzilla.mozilla.org/show_bug.cgi?id=1767811#c9 here]. | |||
#* Note that this should be tested with the real Firefox Release version, not an unbranded build. This testing round is your final chance to catch any errors. | |||
# When your second QA run passed, ask Release Management for formal approval. [https://bugzilla.mozilla.org/show_bug.cgi?id=1767811#c15 This bug comment] is an example. Provide as much detail as you can to make sure Release Management knows everything they need to know. | |||
# After Release Management has signed off, ask a Release Engineer to deploy the rule to the <tt>release</tt> channel. | |||
The update is now live. | |||
=== Follow-up work === | |||
* In the addon's GitHub repo, tag the commit you're rolling out. Push the tag, and merge the <tt>release-hotfix</tt> branch into <tt>main</tt>. This merge will most likely conflict, as the version numbers will disagree. Resolve that conflict by using the current version number from <tt>main</tt> and bump that number by one minor release. | |||
* | * Even though your code is now shipping to release, please make sure to land your changes to <tt>mozilla-central</tt>, <tt>mozilla-beta</tt>, and <tt>mozilla-release</tt>. Nightly and Beta users will not receive your update, and even for Release users, it's important to ship the new addon version in a dot release, since new profiles otherwise won't get the new interventions immediately and have to wait for the background update. See the uplifting docs above, everything still applies. | ||
* | * Make sure to label/close all relevant Bugzilla bugs, apply the <tt>sitepatch-applied</tt> label on GitHub, and all the other cleanup work you do in a regular release. | ||
* Optional: You might be interested in keeping an eye on Telemetry data for the rollout. You can create a copy of [https://sql.telemetry.mozilla.org/queries/85734#212283 this telemetry dashboard (Mozilla-internal)], making sure to change the start date, the Firefox version, and the addon version as needed. If you are running into issues, ask :denschub, or ask in <tt>#data-help</tt> on Slack. | |||
* | |||
* | |||
= | = Interventions Release Rotations = | ||
Engineers on the Web Compatibility team will rotate on ownership of shipping new versions of our interventions addons, serving as an Intervention Release Owner (IRO). The process will follow a predictable 4 week schedule, mirroring the [[Release_Management/Calendar|Firefox release schedule]]. However, we will attempt to land the interventions 1 week before soft freeze (see the schedule above for dates). Another way to look at this is 2 weeks before release. | |||
== | A tracking bug for the next release should be filed in Bugzilla (in the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Web%20Compatibility&component=Interventions <tt>Web Compatibility::Interventions</tt> component]). Bugs for adding or removing interventions in the current release cycle should block this bug. | ||
During bug diagnosis, if a site is identified as a low priority intervention candidate, a <tt>action-needssitepatch</tt> label is added for the next IRO to take care of during their rotation. High priority interventions should be flagged immediately to the IRO who will then begin the process necessary to ship an off-train intervention. | |||
== | == Candidates for interventions == | ||
There is a [https://github.com/webcompat/web-bugs/issues?q=label%3Aaction-needssitepatch dedicated <tt>action-needssitepatch</tt> label on GitHub] as well as a [https://bugzilla.mozilla.org/buglist.cgi?product=Web%20Compatibility&component=Interventions&resolution=--- Bugzilla bug query] for sites that need interventions. During a rotation, you should look at both of these sites and determine which are the most important to work on and ship (or close, if appropriate). | |||
[[Category:Web Compatibility]] | [[Category:Web Compatibility]] | ||