New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 818227 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature

Blocking:
issue 648042



Sign in to add a comment

Setup stable and beta builders for ChromeOS Fuzzing

Project Member Reported by infe...@chromium.org, Mar 2 2018

Issue description

See title.

This is important as otherwise ClusterFuzz is currently giving wrong results that all bugs impact stable and beta. In Chromium land, we either use archived stable and beta builds, OR use revision with omahaproxy to return stable/beta impact.
 
Cc: akes...@chromium.org vapier@chromium.org manojgupta@chromium.org jorgelo@chromium.org cmt...@chromium.org dgarr...@chromium.org llozano@chromium.org
dgarrett@, Do you know the procedure for adding a builder to release/beta branches?
CrOS doesn't have stable/beta branches.  it is up to the TPMs to decide what version gets sent to what channel.

considering all fuzz work has been in ToT, spinning up fuzzers on branches doesn't make sense (as we'd have to backport a lot of things).  i would expect M66 is the first branch we could start conceivably doing this.
Cc: bhthompson@chromium.org
Owner: josa...@chromium.org
Just to check, do you just want to run it on the branch, or do you want to run it as part of each release build running exactly the same code as the release build?

It seems like "on the branch" is probably sufficient and certainly a lot easier, especially if you let it roll out as new branches are created (as vapier@ is saying).

We could need to add a build release branch builder similar to the current branch PFQ builders.

As part of each build is theoretically possible, but would be a slightly different concept and thus probably need some extra work.
So, we dont want to run fuzzers on stable or beta branch. Fuzzers will only be run on trunk branch. Once a crash is found, ClusterFuzz provides a way to know which production branches are affected. To give you that info, we need to archive stable and beta builds as archives. OR give stable/beta impact based on regression range. Regression range right now is a set of two numbers which is build number created.
E.g.
https://storage.cloud.google.com/chromeos-image-archive/amd64-generic-fuzzer/R66-10450.0.0-b236/sysroot_virtual_target-os.tar.xz
build number is 236.
Lets say we know where regression was introduced and its build url, can we create a web service that tells if stable/beta is impacted ?
Labels: OS-Chrome
our release branches are like Chrome's when it comes to versioning.  ToT is always XXXXX.0.0, while branches will have XXXXX.Y.Z (where Y is normally 0).

so if you're looking at R65, it'll be 10323.X.Y which branched from 10323.0.0.
Cc: leecy@chromium.org
We also know which version of Chrome is in every ChromeOS build, so it should be possible to map Chrome build ranges to ChromeOS build ranges.
Status: Assigned (was: Untriaged)
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
Triage nag: This Chrome OS bug has an owner but no component. Please add a component so that this can be tracked by the relevant team.
Components: Infra>Client>ChromeOS>CI
Labels: -Type-Bug Type-Feature

Sign in to add a comment