Mozilla Experimenter

Experimenter is a platform for managing experiments in Mozilla Firefox.

Important Links

Check out the 🌩 Nimbus Documentation Hub or go to the repository that house those docs.

Link	Prod	Staging	Local Dev (Default)
Legacy Home	experimenter.services.mozilla.com	stage.experimenter.nonprod.dataops.mozgcp.net	https://localhost
Nimbus Home	/nimbus	/nimbus	/nimbus
Nimbus REST API	/api/v6/experiments/	/api/v6/experiments/	/api/v6/experiments/
GQL Playground	/api/v5/nimbus-api-graphql	/api/v5/nimbus-api-graphql	/api/v5/nimbus-api-graphql
Remote Settings	settings-writer.prod.mozaws.net/v1/admin	settings-writer.stage.mozaws.net/v1/admin	http://localhost:8888/v1/admin

Installation

General Setup

1. Prerequisites

   On all platforms:

   • Install Node to match current version

   On Linux:

   • Install Docker
   • Install yarn
   • Setup docker to run as non-root

   On MacOS:

   • Install Docker
     • Adjust resource settings
       • CPU: Max number of cores
       • Memory: 50% of system memory
       • Swap: Max 4gb
       • Disk: 100gb+
   • Install yarn

2. Clone the repo

    git clone <your fork>
   

3. Copy the sample env file

    cp .env.sample .env
   

4. Set DEBUG=True for local development

    vi .env
   

5. Create a new secret key and put it in .env

    make secretkey
   

   vi .env

   ...
   SECRETKEY=mynewsecretkey
   ...
   

6. Run tests

    make check
   

7. Setup the database

    make refresh
   

Fully Dockerized Setup (continuation from General Setup 1-7)

1. Run a dev instance

    make up
   

2. Navigate to it and add an SSL exception to your browser

    https://localhost/
   

Semi Dockerized Setup (continuation from General Setup 1-7)

One might choose the semi dockerized approach for:

1. faster startup/teardown time (not having to rebuild/start/stop containers)
2. better IDE integration

Notes:

• osx catalina, reinstall command line tools

• Install poetry

Semi Dockerized Setup Steps

1. Pre reqs macOS instructions:

   brew install postgresql llvm openssl yarn
   
   echo 'export PATH="/usr/local/opt/llvm/bin:$PATH"' >> ~/.bash_profile
   export LIBRARY_PATH=$LIBRARY_PATH:/usr/local/opt/openssl/lib/
   

   Ubuntu 20.04 instructions:

   # general deps (also see `poetry` link above)
   sudo apt install postgresql llvm openssl yarn
   
   # add'l deps* for poetry / python setup
   sudo apt install libpq5=12.9-0ubuntu0.20.04.1
   sudo apt install libpq-dev
   

   *Notes

   • the specific libpq5 version shown here is required for libpq-dev at time of writing
   • poetry install (next step) requires python 3.9, but there are multiple options for resolving this, see here

2. Install dependencies

   source .env
   
   cd app
   poetry install # see note above
   
   yarn install
   

3. env values

   .env (set at root):
   DEBUG=True
   DB_HOST=localhost
   HOSTNAME=localhost
   

4. Start postgresql, redis, autograph, kinto

   make up_db (from project root)
   

5. Django app

   # in app
   
   poetry shell
   
   yarn workspace @experimenter/nimbus-ui build
   yarn workspace @experimenter/core build
   
   # run in separate shells (`poetry shell` in each)
   yarn workspace @experimenter/nimbus-ui start
   ./manage.py runserver 0.0.0.0:7001
   

Pro-tip: we have had at least one large code refactor. You can ignore specific large commits when blaming by setting the Git config's ignoreRevsFile to .git-blame-ignore-revs:

git config blame.ignoreRevsFile .git-blame-ignore-revs

VSCode setup

1. If using VSCode, configure workspace folders

   • Add /experimenter/ and /experimenter/app folders to your workspace (File -> Add Folder to Workspace -> path/to/experimenter/app)
   • From the /experimenter/app folder, run yarn install

     • Make sure you are using the correct version of node

       node -v

     • Troubleshooting:

       • Changing node version
       • Clear npm cache: npm cache clean --force

Google Credentials for Jetstream

On certain pages an API endpoint is called to receive experiment analysis data from Jetstream to display visualization tables. To see experiment visualization data, you must provide GCP credentials.

0. Prequisites

   • Install GCP CLI
     • Follow the instructions here
     • Project: moz-fx-data-experiments
   • Verify/request project permissions
     • Check if you already have access to the storage bucket here
     • If needed, ask in #nimbus-dev for a project admin to grant storage.objects.list permissions on the moz-fx-data-experiments project

1. Authorize CLI with your account

   • make auth_gcloud
     • this will save your credentials locally to a well-known location for use by any library that requests ADC
     • Note: if this returns Error saving Application Default Credentials: Unable to write file [...]: [Errno 21] Is a directory: ..., delete the directory and try again (rm -rf ~/.config/gcloud)

2. The next time you rebuild the docker-compose environment, your credentials will be loaded as a volume

   • Note that this will require the existing volume to be removed (hint: run make refresh)

3. (optional) Verify access

   • make refresh
   • make bash
   • ./manage.py shell

     • from django.core.files.storage import default_storage
       default_storage.listdir('/')
       

     • Confirm this second command prints a list instead of an error

Google Cloud Bucket for Media Storage

We support user uploads of media (e.g. screenshots) for some features.

In local development, the default is to store these files in /app/media using Django's FileSystemStorage class and the MEDIA_ROOT and MEDIA_URL settings.

In production, a GCP bucket and credentials are required.

The bucket name is configured with the UPLOADS_GS_BUCKET_NAME setting. For example:

UPLOADS_GS_BUCKET_NAME=nimbus-experimenter-media-dev-uploads

For local testing of a production-like environment, The credentials should be configured as described in the previous section on Google Credentials for Jetstream.

In the real production deployment, credentials are configured via workload identity in Google Kubernetes Engine.

Usage

Experimenter uses docker for all development, testing, and deployment.

Building

make build

Build the application container by executing the build script

make compose_build

Build the supporting services (nginx, postgresql) defined in the compose file

make ssl

Create dummy SSL certs to use the dev server over a locally secure connection. This helps test client behaviour with a secure connection. This task is run automatically when needed.

make kill

Stop and delete all docker containers. WARNING: this will remove your database and all data. Use this to reset your dev environment.

make migrate

Apply all django migrations to the database. This must be run after removing database volumes before starting a dev instance.

make load_dummy_experiments

Populates the database with dummy experiments of all types/statuses using the test factories

make refresh

Run kill, migrate, load_locales_countries load_dummy_experiments. Useful for resetting your dev environment when switching branches or after package updates.

Running a dev instance

make up

Start a dev server listening on port 80 using the Django runserver. It is useful to run make refresh first to ensure your database is up to date with the latest migrations and test data.

make up_db

Start postgresql, redis, autograph, kinto on their respective ports to allow running the Django runserver and yarn watchers locally (non containerized)

make up_django

Start Django runserver, Celery worker, postgresql, redis, autograph, kinto on their respective ports to allow running the yarn watchers locally (non containerized)

make up_detached

Start all containers in the background (not attached to shell). They can be stopped using make kill.

make update_kinto

Pull in the latest Kinto Docker image. Kinto is not automatically updated when new versions are available, so this command can be used occasionally to stay in sync.

Running tests and checks

make check

Run all test and lint suites, this is run in CI on all PRs and deploys.

make py_test

Run only the python test suite.

make bash

Start a bash shell inside the container. This lets you interact with the containerized filesystem and run Django management commands.

Helpful Python Tips

You can run the entire python test suite without coverage using the Django test runner:

./manage.py test

For faster performance you can run all tests in parallel:

./manage.py test --parallel

You can run only the tests in a certain module by specifying its Python import path:

./manage.py test experimenter.experiments.tests.api.v5.test_serializers

For more details on running Django tests refer to the Django test documentation

To debug a test, you can use ipdb by placing this snippet anywhere in your code, such as within a test method or inside some application logic:

import ipdb
ipdb.set_trace()

Then invoke the test using its full path:

./manage.py test experimenter.some_module.tests.some_test_file.SomeTestClass.test_some_thing

And you will enter an interactive iPython shell at the point where you placed the ipdb snippet, allowing you to introspect variables and call methods

For coverage you can use pytest, which will run all the python tests and track their coverage, but it is slower than using the Django test runner:

pytest --cov --cov-report term-missing

You can also enter a Python shell to import and interact with code directly, for example:

./manage.py shell

And then you can import and execute arbitrary code:

from experimenter.experiments.models import NimbusExperiment
from experimenter.experiments.tests.factories import NimbusExperimentFactory
from experimenter.kinto.tasks import nimbus_push_experiment_to_kinto

experiment = NimbusExperimentFactory.create_with_status(NimbusExperiment.Status.DRAFT, name="Look at me, I'm Mr Experiment")
nimbus_push_experiment_to_kinto(experiment.id)

Helpful Yarn Tips

You can also interact with the yarn commands, such as checking TypeScript for Nimbus UI:

yarn workspace @experimenter/nimbus-ui lint:tsc

Or the test suite for Nimbus UI:

yarn workspace @experimenter/nimbus-ui test:cov

For a full reference of all the common commands that can be run inside the container, refer to this section of the Makefile

make integration_test_legacy

Run the integration test suite for experimenter inside a containerized instance of Firefox. You must also be already running a make up dev instance in another shell to run the integration tests.

make integration_test_nimbus

Run the integration test suite for nimbus inside a containerized instance of Firefox. You must also be already running a make up dev instance in another shell to run the integration tests.

make integration_vnc_up

First start a prod instance of Experimenter with:

make refresh&&make up_prod_detached

Then start the VNC service:

make integration_vnc_up

Then open your VNC client (Safari does this on OSX or just use VNC Viewer) and open vnc://localhost:5900 with password secret. Right click on the desktop and select Applications > Shell > Bash and enter:

cd app
sudo mkdir -m 0777 tests/integration/.tox/logs
tox -c tests/integration/

This should run the integration tests and watch them run in a Firefox instance you can watch and interact with.

Integration Test options

• TOX_ARGS: Tox commandline variables.
• PYTEST_ARGS: Pytest commandline variables.

An example using PYTEST_ARGS to run one test.

make integration_test_legacy PYTEST_ARGS="-k test_addon_rollout_experiment_e2e"

Accessing Remote Settings locally

In development you may wish to approve or reject changes to experiments as if they were on Remote Settings. You can do so here: http://localhost:8888/v1/admin/

There are three accounts you can log into Kinto with depending on what you want to do:

• admin / admin - This account has permission to view and edit all of the collections.
• experimenter / experimenter - This account is used by Experimenter to push its changes to Remote Settings and mark them for review.
• review / review - This account should generally be used by developers testing the workflow, it can be used to approve/reject changes pushed from Experimenter.

The admin and review credentials are hard-coded here, and the experimenter credentials can be found or updated in your .env file under KINTO_USER and KINTO_PASS.

Any change in remote settings requires two accounts:

• One to make changes and request a review
• One to review and approve/reject those changes

Any of the accounts above can be used for any of those two roles, but your local Experimenter will be configured to make its changes through the experimenter account, so that account can't also be used to approve/reject those changes, hence the existence of the review account.

For more detailed information on the Remote Settings integration please see the Kinto module documentation.

Frontend

Experimenter has two front-end UIs:

• core is the legacy UI used for Experimenter intake which will remain until nimbus-ui supersedes it
• nimbus-ui is the Nimbus Console UI for Experimenter that is actively being developed

Learn more about the organization of these UIs here.

Also see the nimbus-ui README for relevent Nimbus documentation.

API

API documentation can be found here

Contributing

Please see our Contributing Guidelines

License

Experimenter uses the Mozilla Public License