Clone this repo:
  1. 1f035d5 [suite_scheduler] Update kernelnext wificell suites by harpreet · 2 days ago master
  2. 3dac647 Merge "Improve the checkout for infra_libs" by Commit Bot · 2 days ago
  3. c98e7bf Merge "OWNERS: update to include OWNERS.testplatform" by Commit Bot · 2 days ago
  4. 0a9c871 Merge "Add hatch-arc-r-userdebug to suite_scheduler.ini" by Commit Bot · 3 days ago
  5. 46efaab Merge "Add hatch_helios 3 times a week on days hatch_kohaku does not run" by Commit Bot · 3 days ago

Suite-Scheduler README

Developer Setup


suite-scheduler is an AppEngine Standard Python Environment V1 application. You need the Google Cloud SDK's AppEngine Python component to develop and deploy this application:

  • Install Google Cloud SDK:
    • Follow the instructions to install the Python App Engine component.
  • Log in to gcloud: gcloud auth login <username>
  • Install App Engine Python extensions
    • gcloud components install app-engine-python
    • gcloud components install app-engine-python-extras

Developer environment

Suite-scheduler development must be done in the standard Chrome OS source checkout but entirely outside the Chrome OS chroot environment.

suite-scheduler uses infra_virtualenv to provide a stable environment for development and release.

First, make sure you install virtualenv with version at least 20.0.

Then, to (re)initialize developer environment, run


For testing changes beyond to the configs/ directory, and for deploying suite-scheduler, you must also obtain certain service credentials used by suite-scheduler.

  bin/setup_environment --load-creds

If you get failures when trying to download credentials,

  • Double check you're logged into the Google Cloud SDK by running gcloud auth list.
  • Contact Test Platform team or one of the OWNERS to be whitelisted.

Testing your changes

Changes to configs/* directory can be tested via sanity tests alone:

  bin/run_sanity_tests --debug  # More verbose

Other changes must be validated with the full test suite:

  bin/run_tests --debug  # More verbose

These tests include some integration tests that can take over 5 minutes to run.

** WARNING: suite-scheduler unittests do not currently run in presubmit. You MUST ensure that unit-tests pass locally for your change. **

Making configuration changes

  • Add or update your job configuration in configs/suite_scheduler.ini.
  • Update configs/lab_config.ini, if the suite test relies on new board or model. Note, suite scheduler does not automatically catch the new boards or models added to the lab.
  • Test your changes.
  • Submit the change and ping/file bug to infra team. Test platform deputy will rollout your change to the production. Once this is done, you may find the scheduling status of the new suite via our dashboard.

Running an instance locally

If you want to verify any APIs locally, you can run suite scheduler v2 as a local development server (

a. Finally, start in a window: app.yaml \
    --port=8888 \
    --admin_port=8001 \

b. Test it:

    curl 'http://localhost:8888/cron/trigger_event', or open it in chrome.

Please note that once a dev_appserver is started, it simulates data_store & task_queue, which means:

a. The datastore doesn‘t contain any previous cron run’s information, so the first round of cron/trigger_event won't trigger any event.

b. The task queue is newly created with 0 tasks in it unless cron/trigger_event adds tasks in it. Dev_appserver restart will cause the local task queue to get purged.

Releasing to production

There are two instances of suite-scheduler:

All releases must follow the following process:

Run bin/deploy -h for more usage information.

If there are issues discovered in prod after release, rollback to the previous version.

  gcloud app versions migrate ${VERSION}