commit | 1f035d58b3973a66ae02e9863375e76ddc49df22 | [log] [tgz] |
---|---|---|
author | harpreet <harpreet@google.com> | Fri Jul 10 01:12:00 2020 |
committer | harpreet <harpreet@google.com> | Fri Jul 10 01:12:00 2020 |
tree | 7bc4b48bf5b7605603d05db4e46ac8baecbcd1ae | |
parent | 3dac64713be4b2ae4fe4a5a2fed3050ada0bf515 [diff] |
[suite_scheduler] Update kernelnext wificell suites Increasing QS priority for kernelnext suites that run in wificell pool and remove hana-kernelnext board from bluetooth_e2e as it is also scheduled to run in wificell_bt_perbuild pool. BUG=None TEST=Suite scheduler sanity Change-Id: I51842db1d9379d9065eee0dcbeaac39d965b8b3f
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.com
gcloud components install app-engine-python
gcloud components install app-engine-python-extras
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
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}