As an ANGLE Sheriff. Your job is to:
- Keep the ANGLE Try Waterfall in good working order.
- Control and monitor the ANGLE auto-rollers.
- Keep the ANGLE Standalone Testers in good working order.
- Keep the SwANGLE Try Waterfall in good working order.
- 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: Please review and if needed update the wrangler schedule.
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.
Note: If you need to suppress test failures (e.g. to keep an auto-roller unblocked), see Handling Test Failures.
Your first job is to keep the ANGLE builders green and unblocked.
There are two consoles for ANGLE continuous integration builders:
- Standalone ANGLE: https://ci.chromium.org/p/angle/g/ci/console
- Chromium + ANGLE integration: https://ci.chromium.org/p/chromium/g/chromium.angle/console
We expect these waterfalls to be perfectly green at all times. As of writing several builders are red or flaky. Part of your job as wrangler is to eliminate all sources of breaks and flakiness. We can fix flakiness by suppressing tests that are not worth fixing, reverting problematic CLs, or finding other solutions.
When you encounter red builds or flakiness, please file an ANGLE bug
and set the label: Hotlist-Wrangler
(search for existing bugs).
In addition to the CI builders, we have a console for try jobs on the ANGLE CV (change verifier):
Some failures are expected on this waterfall as developers test WIP changes. Please watch for persistent sources of flakiness and failure and take action as appropriate by filing bugs, reverting CLs, or taking other action.
If you find a point of failure that is unrelated to ANGLE, please file a
Chromium bug. Set the bug label
Hotlist-PixelWrangler
. Ensure you cc the current ANGLE and Chrome GPU
wranglers, which you can find by consulting
build.chromium.org.
For more information see Filing Chromium Bug Reports below.
Also follow Chromium bugs in the Internals>GPU>ANGLE
component
to be alerted to reports of ANGLE-related breakage in Chrome.
NOTE: When all builds seem to be purple or otherwise broken:
This could be a major infrastructure outage. File a high-priority bug using g.co/bugatrooper.
The GPU Pixel Wrangler is responsible for Chromium bugs. Please file
Chromium issues with the Label Hotlist-PixelWrangler
for bugs outside of
the ANGLE project.
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 bugsInternals>GPU>Testing
for failures that look infrastructure-relatedInternals>GPU>ANGLE
for ANGLE-related Chromium bugsInternals>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.
- Open the first failing and last passing builds.
- For test failures: record
parent_got_angle_revision
in both builds. - For compile failures record
got_angle_revision
. - Create a regression link with this URL template:
https://chromium.googlesource.com/angle/angle.git/+log/<last passing revision>..<first failing revision>
The ANGLE auto-roller automatically updates Chrome with the latest ANGLE changes.
- Roller health: You will be cc'ed on all rolls. Please check failed rolls to verify there is no blocking breakage.
- 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, and Chromium, 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, for example Chromium-side test expectation updates or suppressions. 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.
Occasionally, a vulkan-deps AutoRoll CL will get an error in the presubmit
bot. For example,
see: https://chromium-review.googlesource.com/c/angle/angle/+/3198390 where the
export_targets.py
script had trouble with the loader_windows.h
file. The export_targets.py
script sometimes has difficulty with headers. If you cannot see an obvious problem, create a CL
that adds the header to IGNORED_INCLUDES
in export_targets.py
.
The ANGLE into Chromium roller has two SwiftShader + ANGLE (SwANGLE) builders: linux-swangle-try-x64 and win-swangle-try-x86. However, failures on these bots may be due to SwiftShader changes.
To handle failures on these bots:
- If possible, suppress the failing tests in ANGLE, opening a bug to investigate later.
- If you supsect an ANGLE CL caused a regression, consider whether reverting it or suppressing the failures is a better course of action.
- If you suspect a SwiftShader CL, and the breakage is too severe to suppress, (a lot of tests fail in multiple suites), consider reverting 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, stop the autoroller as well.
See more detailed instructions on by following this link.
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.