The whole project uses Taskcluster secrets as a source of configuration. We use a shared secret amongst every actor of the system, with a hierarchy so that common configurations can be easily shared without duplication.
The source code to manage secrets is in the Taskcluster python library itself.
A developer can also specify its local configuration using a YAML file, with the same exact structure as the secret described below.
We use one secret per environment, on the firefox-ci Taskcluster instance:
project/relman/code-review/runtime-testing
for the testing environmentproject/relman/code-review/runtime-production
for the production environment
# Configuration under the `common` key is shared across the 3 other Python projects (bot, backend & events)
common:
# This defines the environment name, used to customize logging, reporting, ...
# Usual choices are: `testing`, `production` or `localdev`, `dev`
APP_CHANNEL: testing
# This section defines the optional statistics connection for an InfluxDB database.
# This system is used and deployed by Mozilla Cloudops team.
# Of course, it must be disabled on local configurations.
influxdb:
ssl: true
password: xxxx
username: yyyy
database: zzzz
port: 8086
host: something.influxcloud.net
# These two keys allow the project to log everything on Papertrail, so that administrators can troubleshoot the system.
# For more information, see the debugging documentation.
# Of course, it must be disabled on local configurations.
PAPERTRAIL_HOST: logs.papertrailapp.com
PAPERTRAIL_PORT: 12345
# A common Phabricator account is shared across the bot and events projects
# Issues will be published with this account
# This section is required in local configuration
PHABRICATOR:
url: "https://phabricator.services.mozilla.com/api/"
api_key: api-xxxx
publish: true
repositories:
# A unique display name for the repository
- name: mozilla-central
# The repository base url, used to clone the repository
# and reference it in the backend
url: "https://hg.mozilla.org/mozilla-central"
# Try server configuration
# try_url is the ssh connection string to push patches
try_url: "ssh://hg.mozilla.org/try"
# try_name is a display name for that repository
try_name: try
# try_mode describes how the try_task_config is published
# - json, to build a json v2 try_task_config.json
# - syntax, to add a commit with a try syntax as commit message
try_mode: json
# try_syntax is the full commit message used when try_mode = syntax
try_syntax: -p xxx -l code-review
# Mercurial checkout mode, several modes available:
# - robust, to use robustcheckout extension (recommended)
# - batch, to clone from revision 1 up to tip (slow but lower memory usage)
# - default, to use the default hg clone (for small repositories only)
checkout: robust
# Prefix of the environment variables used by the bot to detect which repository
# is setup from a decision task (more details on the bot documentation)
decision_env_prefix: GECKO
# The ssh username (or email) used to push on Try
ssh_user: someone@mozilla.com
# (Optional) private ssh-key overriding the default one setup in the events main section
ssh_key: xxxx
# This main section is only used by the bot project
bot:
# The list of reporter classes used to publish issues
REPORTERS:
# The most important one being Phabricator publication
# You just need to add that line to use the shared phabricator credentials
# Every issues deemed publishable will then be posted on the revision
- reporter: phabricator
# A debugging tool to receive an email on *every* build processed
# with the full list of issues
# Internal use only !
- reporter: mail
emails:
- admin@mozilla.com
# This reporter will send an extra email to the developers when a build error
# is detected amongst the issues
- reporter: build_error
# Boolean option to enable/disable the low coverage warning
ZERO_COVERAGE_ENABLED: true
# Float ratio (between 0.0 and 1.0) defining the chance for a patch to be analyzed with
# the before/after feature (filters out known issues and warn about issues outside the patch)
BEFORE_AFTER_RATIO: 0.3
# Connection information to publish issues on the backend
# On local development it should be set to the local backend running in Docker
backend:
url: "https://api.code-review.moz.tools"
# That user can be created through the administration interface
username: xxxx
password: yyy
# Sentry connection string to publish system exceptions
# Each project has its own Sentry environment
SENTRY_DSN: https://xxx:yyy@sentry.com
# This main section is only used by the backend project
# Note: The postgresql connection string is provided by Heroku as an environment variable
backend:
# Configure a list of allowed domains through CORS
# Useful for another frontend to use data from that backend
# Like on the Taskcluster builds
cors-domains:
- "https://community.taskcluster-artifacts.net"
# Sentry connection string to publish system exceptions
# Each project has its own Sentry environment
SENTRY_DSN: https://xxx:yyy@sentry.com
# This main section is only used by the events project
# Note: The redis connection string is provided by Heroku as an environment variable
events:
# Sentry connection string to publish system exceptions
# Each project has its own Sentry environment
SENTRY_DSN: https://xxx:yyy@sentry.com
# Does the system need to listen for autoland or mozilla-central payloads on pulse
# This is needed to ingest issues in the backend
autoland_enabled: true
mozilla_central_enabled: true
# Pulse authentication to get messages for the autoland and mozilla-central triggers
pulse_user: xxx
pulse_password: yyy
# Parameters for the test selection feature
# TODO: Marco may document a bit more here
bugbug_phabricator_deployment: dev
test_selection_enabled: false
test_selection_share: 0.03
test_selection_notify_addresses:
- admin@mozilla.com
# Skip all revisions produced by these users
# It's useful to avoid huge revisions produced by bots
user_blacklist:
- bot-username-a
- bot-username-b
# Taskcluster credentials for the community instance
# Needed to run the bugbug analysis
taskcluster_community:
client_id: project/relman/bugbug/xxxx
access_token: yyy
# Pulse authentication on the community Taskcluster instance
# to get messages for the test selection triggers
communitytc_pulse_user: xxxx
communitytc_pulse_password: yyy
# Phabricator usernames for whom a risk analysis will be triggered
# when they are authors or reviewers of a patch
risk_analysis_users:
- user-a
- user-b
# The SSH private key used to push patches on the Try server
# It can be setup globally for the events project, or specified per repository
ssh_key: |-
-----BEGIN RSA PRIVATE KEY-----
SomePrivateKeyHere
-----END RSA PRIVATE KEY-----