[ci.yaml] Add section on adding new targets#1329
Conversation
CI_YAML.md
Outdated
|
|
||
| The target will show runs in https://ci.chromium.org/p/flutter (under the repo). See | ||
| https://github.com/flutter/flutter/wiki/Adding-a-new-Test-Shard for up to date information | ||
| on the steps to promote your target to blocking. In general, this involves 10 consecutive green |
There was a problem hiding this comment.
For framework, 50 consecutive green runs are needed as of now (based on SLO 2%).
There was a problem hiding this comment.
Nit: the auto deflake process is running only on framework repo and the 50 is also only applicable to the framework.
|
|
||
| ## Adding new targets | ||
|
|
||
| All new targets should be added as `bringup: true` to ensure they do not block the tree. |
There was a problem hiding this comment.
We want to enforce adding the target in staging pool first before moving it to the prod, even with bringup: true. Could you add a comment here?
BTW: do we have plans to support staging targets in the .ci.yaml?
There was a problem hiding this comment.
My understanding of staging is that we want it for new testbeds, not necessarily new tests. Is there a doc with more details?
I can add support for .staging_ci.yaml with all the plumbing to generate these staging builders, but this doc is intended for developers.
There was a problem hiding this comment.
It will be for any new test, not only a new testbed.
Thanks. I will /cc you when that section is ready.
There was a problem hiding this comment.
Would the plan be to deprecate the bringup field then? For example, what about re-sharding tests. Are those new tests?
There was a problem hiding this comment.
No. The bringup will still be helpful for existing tests that are flaky. Only those new tests or old ones that have not been running for a while need to go through the staging pool.
Since the shard tests have been running, the re-sharding probably not need to follow.

No description provided.