[SERVER-55650] Bring more structure and order to build variant naming Created: 30/Mar/21  Updated: 27/Oct/23  Resolved: 27/Oct/23

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: 6.0 Desired

Type: Improvement Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Development Platform
Backwards Compatibility: Fully Compatible
Participants:

 Description   

We currently offer four visually distinct types of build variants on master:

  • The builders with a leading ! in the display name, which have variant names that end with -required. This pattern indicates a required builder.
  • The builders with a leading * in the display name, which have variant names that end with -suggested. This pattern indicates a builder that is suggested when a patch build warrants additional coverage beyond what the usual -required builders offer.
  • The builders with a leading ~ in the display name, which do not have any pattern to the variant name. In general, these have been intended for "experiments" or for "non-release" builds.
  • The builders with no special leading sigil.

The situation with the -required and -suggested variants is mostly consistent and reasonable, but the situation with the remaining variants is far less regular. For instance:

  • Most of the *SAN variants are currently tagged with ~, but these aren't really experiments at all. They are real builders and have been around for years.
  • We have no consistent annotation either in the display name or the variant name which indicates that a variant is a release variant (e.g., something that "leaves the building"), or that it isn't.

There are a few things we could do to help make things more orderly:

  • We could reinterpret ~ to mean non-shipping (as perhaps it originally did), and tag all non-shipping releases with ~ in the display name and prefix the variant name with noship- or nopush- or similar.
  • We could tag all shipping releases with RELEASE in the display name and prefix the variant name with release-, to clearly identify which builders are release builders. As we would then have a clear way to identify releases, we could refine the meaning of ~ to truly mean "experiment", and remove the ~ sigil from the builders that aren't experiments, like ASAN.

Other schemes or modifications are certainly possible.


Generated at Thu Feb 08 05:37:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.