it's the same category as amd64-generic-asan.  instead of using the ASAN sanitizer, it uses the UBSAN sanitizer.  both configs build Chrome from source with USE=asan turned on.

imo these bots should stay together.  yesterday you said you wanted the amd64-generic-asan bot to stay in the Chrome PFQ category.

Here is the output from BuildPackages for the ubsan builder:

https://luci-logdog.appspot.com/v/?s=chromeos/buildbucket/cr-buildbucket.appspot.com/8934774452387204640/+/steps/BuildPackages/0/stdout

[ebuild  N     ] chromeos-base/chromeos-chrome-71.0.3555.0_rc-r1::chromiumos to /build/amd64-generic/ USE="accessibility authpolicy autotest build_tests buildcheck chrome_debug chrome_remoting clang cups debug_fission evdev_gestures fonts gold highdpi libcxx nacl opengles runhooks smbprovider v4l2_codec vaapi xkbcommon -afdo_use -app_shell -asan -build_native_assistant (-cfi) -chrome_debug_tests -chrome_internal -chrome_media -clang_tidy -component_build -goma -hardfp -internal_gles_conform -jumbo -lld -mojo (-neon) -oobe_config -opengl (-thinlto) -v4lplugin -verbose -vtable_verify" OZONE_PLATFORM="gbm -caca -cast -egltest {-test}" OZONE_PLATFORM_DEFAULT="gbm -caca -cast -egltest {-test}" 0 KiB

USE="-asan" for chromeos-chrome.

i loaded up both asan/ubsan logs, but i must have confused all the tabs i loaded when i looked for the chromeos-chrome ebuild line

imo, the sanitizer bots should all stay together.  since they're doing double duty for OS & browser sanitizing, and you want to keep the asan bot in the Chrome PFQ, then for OS people looking at asan failures, it's reasonable they only have to go to one place.

maybe what we really want isn't to put configs into a single category but have a label system where the buckets on the left show bots by those labels.  then we can have asan-generic in both Chrome PFQ & an ASAN section.

Allowing builders to show up in multiple sections would be great.

Alternately/additionally we could remove "asan" for chromeos-chrome from the amd64-generic-asan builder and add an amd64-generic-chrome-asan builder that just builds chrome with asan.

Multiple sections isn't feasible today. The builds have a "display_label", but there can only be a single label on a give build run. Changing that label for a given build config is a really simple build config change. Adding additional labels is harder (requires a matching Legoland change).

Changing what gets / doesn't get asan applied during a build is a cbuildbot code change to the stages in question. I'm not really sure how hard or easy that would be to do.

Not knowing about this bug, I recently filed  issue 908667 , requesting that amd64-generic-asan and betty-asan be removed from chrome_informational.

I've never found these to be at all useful when I'm the gardener. Every single ASAN build for the last few months has been red, and I couldn't find any cases where they caught Chrome issues rather than OS issues. They clutter the list of informational builders and distract me from Chrome issues.

Are there any objections to me duping  issue 908667  into this one and widening this to be a request to drop all asan and ubsan builders from chrome_informational? I'm also sending a message to the chrome-os-gardeners mailing list to see how other gardeners feel.

All that's required is changing the display_label from CHROME_INFORMATIONAL to INFORMATIONAL (assuming they belong in the informational section).

New builds will be moved. Old ones will remain visible where they are until they age out of the display. This is a known limit in how Legoland decides where to display things.

Re having builders that compile Chrome with ASan and the rest of the OS without it, I don't have any objections. I don't have much state about how to do that, but after poking around in chromite, I think that the steps may be something like this:

a) In src/overlays, add a overlay-amd64-generic/profiles/chrome_asan directory with a package.use file that sets the following (probably):

  asan -cfi -thinlto

See overlay-amd64-generic/profiles/asan for what I think we do with the existing "asan" profile.

b) In chromite, edit config/chromeos_config.py to add a new 'chrome_asan' template using the 'chrome_asan' profile. See the existing 'asan' template for guidance.

c) In chromite, add builder configs as desired.

I'll repurpose this bug to track that and use  issue 908667  to track my request to remove the existing everything-ASan builders from CHROME_INFORMATIONAL. I think that that can and should happen independently of new Chrome-ASan configs being created.