In .ci.yaml, targets can be marked with bringup: true. The intended purpose of bringup: true is to allow new or experimental test targets to be onboarded and validated in postsubmit CI without blocking the tree (i.e. skipped in presubmit and non-blocking in postsubmit).
Currently, Cocoon conflates bringup with LUCI's staging bucket. When a target is marked bringup: true, Cocoon:
- Schedules the postsubmit build in the staging LUCI bucket instead of prod.
- Runs the task against the staging pool of bots (luci.flutter.staging).
- Generates dashboard links and build log URLs pointing to staging builders.
Coupling bringup with staging is unnecessary and misuses the staging fleet. bringup: true is a property of the test target (indicating that the test is new/experimental and should not block the tree). It should run on the standard production testbed to accurately reflect how the test will behave when promoted. In contrast, the staging pool/bucket is intended for validating bot/infrastructure configurations (e.g., testing new machine images, OS versions, or experimental testbed hardware without disrupting normal CI traffic, typically tested via led).
Running bringup tests on staging bots means tests are validated against an experimental bot pool rather than the production environment they will eventually run on. Instead, postsubmit and merge queue builds should always be scheduled in the prod bucket (luci.flutter.prod), regardless of whether bringup is true or false. Targets have no intrinsic bucket. Presubmit uses try, and postsubmit / merge queue uses prod.
Decoupling these will also allow us to repurpose the bots in the staging pool to the try/prod pools. As of right now, we have to maintain a handful of bots in the staging pool since bringup tasks may need to use them. Once we decouple bringup from the staging environment, the staging environment will only need to be used for new or experimental bot configurations that need testing, and so we can keep the staging pool otherwise empty.
In .ci.yaml, targets can be marked with bringup: true. The intended purpose of bringup: true is to allow new or experimental test targets to be onboarded and validated in postsubmit CI without blocking the tree (i.e. skipped in presubmit and non-blocking in postsubmit).
Currently, Cocoon conflates bringup with LUCI's staging bucket. When a target is marked
bringup: true, Cocoon:Coupling bringup with staging is unnecessary and misuses the staging fleet.
bringup: trueis a property of the test target (indicating that the test is new/experimental and should not block the tree). It should run on the standard production testbed to accurately reflect how the test will behave when promoted. In contrast, the staging pool/bucket is intended for validating bot/infrastructure configurations (e.g., testing new machine images, OS versions, or experimental testbed hardware without disrupting normal CI traffic, typically tested via led).Running bringup tests on staging bots means tests are validated against an experimental bot pool rather than the production environment they will eventually run on. Instead, postsubmit and merge queue builds should always be scheduled in the prod bucket (luci.flutter.prod), regardless of whether bringup is true or false. Targets have no intrinsic bucket. Presubmit uses try, and postsubmit / merge queue uses prod.
Decoupling these will also allow us to repurpose the bots in the staging pool to the try/prod pools. As of right now, we have to maintain a handful of bots in the staging pool since bringup tasks may need to use them. Once we decouple
bringupfrom the staging environment, the staging environment will only need to be used for new or experimental bot configurations that need testing, and so we can keep the staging pool otherwise empty.