acab911351
In order to extract the PNG files produced by our CanvasKit gms, we need our JS tests to POST them to a server which can write to disk. The easiest way to do this is to use the test_on_env rule defined in the Skia Infra repo for exactly this purpose. This required https://skia-review.googlesource.com/c/buildbot/+/510717 to be able to configure the binary correctly and https://skia-review.googlesource.com/c/buildbot/+/511862, for nicer debugging so the skia-infra dep was updated via the following commands: $ go get go.skia.org/infra@d8a552a29e $ go mod download $ make -C infra/bots train $ make -C bazel gazelle_update_repo This caused many automated changes to infra/bots/tasks.json The flow is: 1. User types bazelisk test :hello_world_test_with_env 2. The test_on_env rule starts gold_test_env and waits for the file defined in $ENV_READY_FILE to be created. 3. gold_test_env starts a web server on a random port. It writes this port number to $ENV_DIR/port. Then, it creates $ENV_READY_FILE to signal ready. 4. test_on_env sees the ready file and then starts the karma_test rule. (Reminder: this is a bash script which starts karma using the Bazel-bundled chromium). 5. The karma_test rule runs the karma.bazel.js file (which has been injected with some JS code to fill in Bazel paths and settings) using Bazel-bundled node. This reads in the port file and sets up a Karma proxy to redirect /gold_rpc/report to http://localhost:PORT/report 6. The JS tests run via Karma (and do assertions via Jasmine). Some tests, the gms, make POST requests to the proxy. 7. gold_test_env gets these POST requests writes the images to a special Bazel folder on disk as defined by $TEST_UNDECLARED_OUTPUTS_DIR. 8. test_on_env identifies that the tests finish (because the karma_test script returns 0). It sends SIGINT to gold_test_env. 9. gold_test_env stops the webserver. The special Bazel folder will zip up anything inside it and make it available for future rules (e.g. a rule that will upload to Gold via goldctl). Suggested Review Order: - bazel/karma_test.bzl to see the test_on_env rule bundled into the karma_test macro. I chose to put it there because it might be confusing to have to define both a karma_test and test_on_env rule in the same package but not be able to call one because it will fail to talk to the server. - gold_test_env.go to see how the appropriate files are written to signal the environment is ready and the handlers are set up. - karma.bazel.js to see how we make our own proxy given the port from the env binary. The fact that we could not create our own proxy with the existing karma_test rule was why the chain ending in https://skia-review.googlesource.com/c/skia/+/508797 had to be abandoned. - tests/*.js to see how the environment is probed via /healthz and then used to make POST requests with data. - Everything else. Change-Id: I32a90def41796ca94cf187d640cfff8e262f85f6 BUG: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/510737 Reviewed-by: Leandro Lovisolo <lovisolo@google.com> |
||
---|---|---|
.. | ||
analysis | ||
assets | ||
buildstats | ||
gen_tasks_logic | ||
recipe_modules | ||
recipes | ||
task_drivers | ||
tools/luci-go | ||
build_task_drivers.sh | ||
bundle_recipes.sh | ||
cfg.json | ||
check_deps.py | ||
gen_tasks.go | ||
git_utils.py | ||
infra_tests.py | ||
jobs.json | ||
Makefile | ||
README.md | ||
README.recipes.md | ||
recipes.py | ||
run_recipe.py | ||
tasks.json | ||
test_utils.py | ||
utils.py | ||
zip_utils_test.py | ||
zip_utils.py |
Skia Infrastructure
This directory contains infrastructure elements.
Tasks and Jobs
Files in this directory define a DAG of tasks which run at every Skia commit. A task is a small, self-contained unit which runs via Swarming on a machine in the pool. Tasks may be chained together, eg. one task to compile test binaries and another to actually run them.
Jobs are collections of related tasks which help define sub-sections of the DAG, for example, to be used as try jobs. Each job is defined as an entry point into the DAG.
The tasks.json file in this directory is the list of tasks and jobs for the repo. Note that tasks.json is NEVER edited by hand but generated via gen_task.go and the input files enumerated below. The Task Scheduler reads the tasks.json file at each commit to determine which jobs to run. For convenience, gen_tasks.go is provided to generate tasks.json and also to test it for correct syntax and detecting cycles and orphaned tasks. Always edit gen_tasks.go or one of the following input JSON files, rather than tasks.json itself:
- cfg.json - Basic configuration information for gen_tasks.go.
- jobs.json - The list of all jobs to run. Edit this to add or remove bots.
Whenever gen_tasks.go, any of the above JSON files, or assets are changed, you need to run gen_tasks.go to regenerate tasks.json:
$ go run infra/bots/gen_tasks.go
Or:
$ cd infra/bots; make train
There is also a test mode which performs consistency checks and verifies that tasks.json is unchanged:
$ go run infra/bots/gen_tasks.go --test
Or:
$ cd infra/bots; make test
Recipes
Recipes are the framework used by Skia's infrastructure to perform work inside of Swarming tasks. The main elements are:
- recipes.py - Used for running and testing recipes.
- recipes - These are the entry points for each type of task, eg. compiling or running tests.
- recipe_modules - Shared modules which are used by recipes.
- .recipe_deps - Recipes and modules may depend on modules from other repos. The recipes.py script automatically syncs those dependencies in this directory.
Isolate Files
These files determine which parts of the repository are transferred to the bot when a Swarming task is triggered. The Isolate tool hashes each file and will upload any new/changed files. Bots maintain a cache so that they can efficiently download only the files they don't have.
Assets
Artifacts used by the infrastructure are versioned here, along with scripts for recreating/uploading/downloading them. See the README in that directory for more information. Any time an asset used by the bots changes, you need to re-run gen_tasks.go.
Tools
Assorted other infrastructure-related tools, eg. isolate and CIPD binaries.
CT
Helpers for running Skia tasks in Cluster Telemetry.