Later phase and Shipit is smart enough to backfill tasks from uninitiated earlier phases. Note: by design, it is possible to only click a In most cases, you would trigger each phase individually, one at a time. Ship - This final phase will make the release live and available on and start serving updates to existing It will also do some final update testing. Push - This phase takes all the build artifacts that were promoted and uploaded to the staging location on archive.m.oĪnd pushes (copies) them to a final archive.m.o directory. Our update server, Balrog, and running install and update testing. Common tasks in this phase are signing, creating localization specificīuilds, uploading build artifacts to a staging location on (S3), staging the release on Of release automation that does just that. Takes existing per-checkin builds from CI and signs, repacks, and publishes those to users. Promote - as mentioned above, Shipit and release automation do not actually create any new Firefox builds. Most products, there are three phases: “promote”, “push”, and “ship”. Merely primes the release in Shipit so that you can start triggering the various phases.įor more on how to create a release in Shipit, including UI screenshots, see Relman’s documentation Trigger the phases of the release #Īfter creating a release in Shipit, you can see it via the “Releases” tab. Note this does not actually kick off any release automation. Once the form is filled out, click Start tracking it. This often happens when the releaseĪutomation fails or or Firefox fails to pass QA. Times we have had to create and recreate a release prior to shipping it to users. Version and build number - both of these are auto populated and can not be modified. To see the builds of a given pushed revision, use Treeherder. For that reason, the revision must have builds started or complete and associated with the target Instead, the automation will take existingīuilds from the revision that was created and built when that revision was pushed (checked in). Which versions are currently the most used by users.Ī note on release promotion: Releases do not create new builds of Firefox. The auto-populated versions are usually based on Version and the new version of Firefox you are about to create and ship. The list of partials are previous released versions that users are usingĬurrently that we want to provide a special update to that is small in download size and is a diff of the user’s current Partials - partials should be auto populated. ![]() Release ETA - If you are asked to give a “Release ETA”, you do not need to fill this out. Revision - you must use a valid revision from the chosen channel. ![]() Choose the target channel, e.g.īeta, and select the desired revision you would like to ship from. Initiate a new release #įrom Shipit, click on “New Release”. Trigger the various phases of the releaseĬonnect to the VPN. Once you have the permissions to conduct a release, the following is a walkthrough of how to do it. Specific steps required to initiate and release Firefox # In order to initiate and ship a Firefox release, follow these steps to be granted the Troubleshooting Expirations NotificationsĪdding a keyword to mochitest and xpcshell manifestsĪdding a keyword to reftest style manifestsįirefox Release Process # Requirements and permissions to conduct a release # How to rotate the Firefox Release signing GPG Key Testing and Customizing Release Promotion actionsĬreate a new release key to sign a new apk product Turning on Firefox tests for a new configuration Off-Cycle Partner Repacks and Funnelcakes How to automate nightly Google Play deployments Scriptworker-scripts Wiki (mac signing procedures)
0 Comments
Leave a Reply. |