1510612 - Create a new "build_variant" attribute

Status: NEW

(Firefox Build System :: Task Configuration, task)

Description

[Andrew Halberstadt [:ahal]]

There's long been a conflation between "build type" and "build variant". Back in the day, there was only "opt", "debug" and "pgo". While "pgo" was often referred to as a build type, it didn't quite fit, as "pgo" builds were actually opt with this extra thing happening to them.

Now we also have:

* asan
* tup
* ccov
* fuzzing
* fuzzing-ccov
* noopt
* msvc
* rusttests
* mingwclang
* plain

to name a few. All of those things are sometimes colloquially called "buildtypes", though they are all either "opt" or "debug" in addition. Recently this conflation has caused me problems in two different areas:

1) My |mach try chooser| prototype I'm working on in bug 1499822
2) An active data recipe I'm building to find skipped tests

I'd like to formalize what these things are. I see two options:

A) These are legit buildtypes, so let's set their 'build_type' attribute appropriately (e.g build_type == "pgo")

B) These are better thought of as "build variants" (or insert better name), so let's create a new "build_variant" attribute so we have a way of filtering them from the taskgraph or ActiveData.

I suspect there is a ton of hardcoded "opt"/"debug" buildtype code scattered all over the place, so A) has the potential to be massively disruptive. I propose we go with option B).

Comment 1

[Justin Wood (:Callek)]

(In reply to Andrew Halberstadt [:ahal] from comment #0)
> A) These are legit buildtypes, so let's set their 'build_type' attribute
> appropriately (e.g build_type == "pgo")
> 
> B) These are better thought of as "build variants" (or insert better name),
> so let's create a new "build_variant" attribute so we have a way of
> filtering them from the taskgraph or ActiveData.
> 
> I suspect there is a ton of hardcoded "opt"/"debug" buildtype code scattered
> all over the place, so A) has the potential to be massively disruptive. I
> propose we go with option B).

I should note that the work I'll be hopefully working on soon (talked about in) https://groups.google.com/d/msg/mozilla.dev.planning/JomJmzGOGMY/vytPViZBDgAJ is going to be equally disruptive with regards to the A plan, and I support the A plan in general.

But I think even with that we will have a class of things that don't fit and are better known as "variants" indeed.

So I think a C (if different than how you envision B) is in order:

C) Add the variant name as a new attribute, but change nothing else about the existing labels/types code throughout. 

Unless we do want to conflate this work with "Shippable Builds" - though given your ActiveData desire here I don't think that is desirable in terms of timeline

Comment 2

[Andrew Halberstadt [:ahal]]

Yeah, I think B and C are the same. I guess we could do that, and if you end up removing the need for "build_variants" with your shippable builds work, we can always get rid of them again at that point.