ANGLE Wrangling

As an ANGLE Sheriff. Your job is to:

  1. Keep the ANGLE Try Waterfall in good working order.
  2. Monitor the Chromium GPU FYI Waterfall and respond to ANGLE bugs.
  3. Control and monitor the ANGLE auto-rollers.
  4. Keep the ANGLE Standalone Testers in good working order.
  5. Keep the SwANGLE Try Waterfall in good working order.
  6. Monitor and respond to ANGLE's Perf alerts

If you're not an ANGLE team member, you can contact us on the public ANGLE project Google group.

Note: It‘s highly recommend that all wranglers install the Chromium Flake Linker extension for inspecting bot builds. It’ll save you a lot of time.

Task 1: Monitor ANGLE CI and Try Testers

Your first job is to keep the ANGLE Try Waterfall healthy. These are also known as the CQ (commit queue) bots. Some failures are expected on this waterfall. Developers might be testing expectedly buggy code. However, persistent flakiness and failures should be reported and appropriate CLs reverted.

For ANGLE issues that require CLs, please file an ANGLE bug and set the Label Hotlist-Wrangler on the bug. Click here to see those bugs.

When encountering an unexpected failure in a CL that looks ANGLE related, please file an ANGLE bug and cc the current ANGLE wrangler. If the failure is unrelated to ANGLE file a Chromium bug and set the Label Hotlist-PixelWrangler on the bug (see Filing Chromium Bug Reports below). Refer to to find the current ANGLE wrangler and GPU Pixel Wrangler.

NOTE: When all builds seem to be purple or otherwise broken:

This could be a major infrastructure outage. File a high-priority bug using

Task 2: Monitor Chromium FYI Testers and Respond to Bugs

ANGLE bugs sometimes make it past the commit queue testing and into the main branch. This can be because of flaky tests or because the failures are specific to system configurations for which we lack full pre-commit testing support.

The Chromium GPU FYI Waterfall waterfall includes a number of these one-off specialized configurations. Monitor this console for persistent breakage that could be related to ANGLE. Also follow Chromium bugs in the Internals>GPU>ANGLE component to be alerted to reports of breakage on the GPU.FYI waterfall.

Googlers can use sheriff-o-matic to monitor the health of the GPU.FYI waterfall.

Filing Chromium Bug Reports

The GPU Pixel Wrangler is responsible for the Chromium bugs. Please file issues with the Label Hotlist-PixelWrangler for bugs that aren't caused by ANGLE regressions.

IMPORTANT info to include in Chromium bug reports:

  • Links to all first failing builds (e.g. first windows failure, first mac failure, etc).
  • Related regression ranges. See below on how to determine the ANGLE regression range.
  • Relevant error messages.
  • Set the Components to one or more value, such as (start typing “Internals” and you'll see choices):
    • Internals>GPU for general GPU bugs
    • Internals>GPU>Testing for failures that look infrastructure-related
    • Internals>GPU>ANGLE for ANGLE-related Chromium bugs
    • Internals>Skia for Skia-specific bugs
  • Cc relevant sheriffs or blame suspects, as well as yourself or the current ANGLE Wrangler.
  • Set the Hotlist-PixelWrangler Label.

How to determine the ANGLE regression range on the GPU.FYI bots:

  1. Open the first failing and last passing builds.
  2. For test failures: record parent_got_angle_revision in both builds.
  3. For compile failures record got_angle_revision.
  4. Use this URL:<last passing revision>..<first failing revision>

Task 3: The Auto-Rollers

The ANGLE auto-roller automatically updates Chrome with the latest ANGLE changes.

  1. Roller health: You will be cc'ed on all rolls. Please check failed rolls to verify there is no blocking breakage.
  2. Chrome Branching: You are responsible for pausing the roller 24h before branch days, and resuming afterwards. See the Chrome Release Schedule.

We also use additional auto-rollers to roll third party libraries into ANGLE once per day:

Please ensure these rollers are also healthy and unblocked. You can trigger manual rolls using the dashboards to land high-priority changes. When a roll fails, stop the roller, determine if the root cause is a problem with ANGLE or with the upstream repo, and file an issue with an appropriate next step.

The autoroller configurations live in the skia/buildbot repository in the autoroll/config folder.

NOTE: vulkan-deps consists of several related Vulkan dependencies:

vulkan-deps houses Vulkan-Tools, Vulkan-Loader, Vulkan-ValidationLayers, Vulkan-Headers and other related repos. If the roll fails, you will have to determine the correct upstream repo and file an issue upstream. For more info on vulkan-deps see the README.

Task 4: ANGLE Standalone Testing

See more detailed instructions on by following this link.

Task 5: Monitor SwANGLE CI and Try Testers

Most important task here is to keep healthy the 2 SwANGLE bots on ANGLE CQ, linux-swangle-try-tot-angle-x64 and win-swangle-try-tot-angle-x86. As well as the 2 SwANGLE bots used for ANGLE rolls on Chromium CQ, linux-swangle-try-x64 and win-swangle-try-x86.

Same instructions as for Task 1 apply here. Some failures on these bots may be due to SwiftShader changes, however. The possible ways to handle these failures are:

  1. If possible, suppress the failing tests in ANGLE, opening a bug to investigate these later.
  2. If it is clear that an ANGLE CL caused a regression, consider whether reverting it or suppressing the failures is a better course of action.
  3. If a SwiftShader CL is suspected, and the breakage is too severe to be suppressed, (a lot of tests fail in multiple suites), it is possible to revert the responsible SwiftShader roll into Chromium and open a SwiftShader bug. SwiftShader rolls into Chromium should fail afterwards, but if the bad roll manages to reland, the autoroller needs to be stopped.

A lower priority task here is to keep healthy all the SwANGLE CI and Try bots.

Task 6: Monitor and respond to ANGLE's perf alerts

Any large regressions should be triaged with a new ANGLE bug linked to any suspected CLs that may have caused performance to regress. If it's a known/expected regression, the bug can be closed as such. The tests are very flaky right now, so a WontFix resolution is often appropriate.