| commit | c98e7bf8e7339d3b89c4398afd0ff8abb341015f | [log] [tgz] |
|---|---|---|
| author | Commit Bot <commit-bot@chromium.org> | Thu Jul 09 15:25:01 2020 |
| committer | Gerrit Code Review <noreply-gerritcodereview@google.com> | Thu Jul 09 15:25:01 2020 |
| tree | bd765083c0d952e68dd28f0293aaa53800f76819 | |
| parent | 0a9c871b06e489b9f3cd5fa1cac9f54d3456736b [diff] | |
| parent | aeffa415dbc6d4cc877bc512447c531c3be1f577 [diff] |
Merge "OWNERS: update to include OWNERS.testplatform"
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:
gcloud auth login <username>@google.comgcloud components install app-engine-pythongcloud components install app-engine-python-extrasSuite-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
bin/setup_environment
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,
gcloud auth list.Changes to configs/* directory can be tested via sanity tests alone:
bin/run_sanity_tests bin/run_sanity_tests --debug # More verbose
Other changes must be validated with the full test suite:
bin/run_tests 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. **
configs/suite_scheduler.ini.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.If you want to verify any APIs locally, you can run suite scheduler v2 as a local development server (https://cloud.google.com/appengine/docs/standard/python/tools/using-local-server):
a. Finally, start dev_appserver.py in a window:
dev_appserver.py app.yaml \
--port=8888 \
--admin_port=8001 \
--log_level=debug
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.
There are two instances of suite-scheduler:
All releases must follow the following process:
bin/deploy
cron/test_push. Verify there are no obvious failures by looking at service logs.bin/deploy -p
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 --project=google.com:suite-scheduler ${VERSION}