Dawn uses Chromium‘s continuous integration (CI) infrastructure to continually run tests on changes to Dawn and provide a way for developers to run tests against their changes before submitting. CI bots continually build and run tests for batches of new changes (although in practice, it is often once per submitted CL), and Try bots build and run developers’ pending changes before submission. Dawn uses two different builder setups:
For additional information on GPU testing in Chromium, please see [chromium/src]//docs/gpu/gpu_testing_bot_details.md.
Standalone Dawn builders are defined in the following Starlark files, which are used to generate files consumed by the builders when running //infra/config/global/main.star:
There are additional chromium/try builders, but those are described later in this document.
These bots are defined in both buckets luci.dawn.ci and luci.dawn.try, though their ACL permissions differ. luci.dawn.ci bots will be scheduled regularly based on [dawn]//infra/config/global/luci-scheduler.cfg. luci.dawn.try bots will be triggered on the CQ based on [dawn]//infra/config/global/commit-queue.cfg.
Build status for both CI and Try builders can be seen at this console which is generated from [dawn]//infra/config/global/luci-milo.cfg.
There are two recipes for building Dawn/Tint, one for GN based builds and one for CMake based builds.
The specific instructions on how to build the project are contained in the project repos build files. These recipe files are primary concerned with coordinating how to build and test the project for CQ/CI. The high level steps of this process:
dawn.node or fuzzing enabled in addition to the default build optionsNote: For Googlers there is an internal doc (go/dawn-luci-guide) with details on how to update the build recipes and test them.
The chromium.dawn waterfall consists of the bots specified in the chromium.dawn section of [chromium/src]//testing/buildbot/waterfalls.pyl. Bots named “Builder” are responsible for building top-of-tree Dawn, whereas bots named “DEPS Builder” are responsible for building Chromium's DEPS version of Dawn.
The other bots, such as “Dawn Linux x64 DEPS Release (Intel HD 630)” receive the build products from the Builders and are responsible for running tests. The Tester configuration may specify mixins from [chromium/src]//testing/buildbot/mixins.pyl which help specify bot test dimensions like OS version and GPU vendor. The Tester configuration also specifies test_suites from [chromium/src]//testing/buildbot/test_suites.pyl which declare the tests are arguments passed to tests that should be run on the bot.
The parent builders and child testers are configured in Chromium's //infra/config/ files. CI builders are defined here while try builders are defined here.
This Starlark file defines mirrors of Chromium trybots for use as Dawn trybots. This allows Dawn changes to be tested in tests which require Chromium before actually attempting to roll Dawn into Chromium, such as running the WebGPU CTS in a full Chromium browser. The chromium_dawn_tryjob entries define mirrors which are automatically added to all Dawn CLs. These correspond to builder names such as linux-dawn-rel or mac-dawn-rel. The luci.cq_tryjob_verifier entries define manual-only trybot mirrors. These are never automatically added, but can be manually added through Gerrit or CL footers.
Dawn shares all of its builder capacity and test hardware with the Chrome GPU team. Pool assignments for both are defined in this file (Google only). A capacity dashboard for these physical machines and GCE instances can be found at go/chrome-gpu-capacity-dashboard (Google only).
Note: At the time of writing, it is recommended to select “Old UI” at the top right of the capacity dashboard, as the new UI has some performance issues.
While all builders for a given OS share the same pools (e.g. all Linux trybots share the same pool of Linux GCE instances), builders typically have max_concurrent_builds set to limit how many builds can be running at once. This is to smooth out usage spikes and help prevent the physical test hardware from being overwhelmed.