You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is the official mono repo containing all the scriptworker *scripts.
As to November 2019, we have migrated all the workers, across all trees, to Kubernetes and Google Compute Cloud.
Tagging along, we have also migrated all the individual scripts under the same roof in order
to single source the shared configurations.
In a nutshell, we now user Docker-based scriptworkers scripts that perform various pieces of our automation.
In order for deploying, we no longer rely on hiera or puppet but on Docker and SOPS.
The comprehensive list of workers that we have available is listed below. They are
split in two large environments within the GCP: releng-nonprod and releng-prod.
The former holds all the dev workers. These are handy to use before submitting
a PR or deployment to production in order to test things out. The environment
holds rules for netflows as well in order to access the dev instances of our
external resources.
The latter, releng-prod withhold two sets of workers. The level-3 workers
which are the production ones. We use these workers to ship the real, production-ready
releases, across our different products (Firefox, Thunderbird, Firefox for mobile related suite, etc).
In the same environment we also have the level-1 workers which are used for
staging releases. They co-exist here so that they are closer to production
as possible.
# from scriptworker-scripts/ ; this will run docker for py38 and py311
# for all *scripts to update all the dependencies via `pip-compile-multi`
$ maintenance/pin.sh
Testing code changes
Each directory is a different tool with different testing needs.
When updating the entire set of tools here are a few steps that could help:
push changes to dev branch (if a single tool, use dev-<tool>), wait for deployment in #releng-notifications in Slack
git push --dry-run upstream <my_pr_branch>:dev
do a staging release of an xpi manifest (covers github script, signingscript, shipitscript)
Then run ./mach try fuzzy --full and select build-signing, release-balrog, balrog-en-CA, beetmover jobs. This will select hundreds of jobs (mostly language repacks), but will get a lot of coverage
For all of these (just 1 language pack), examine the logs to ensure using the -dev workers and that there are no red flags (like an error that doesn't cause the job to fail)