Skip to content

Comments

[ci.yaml] Add section on adding new targets#1329

Merged
fluttergithubbot merged 4 commits intomasterfrom
CaseyHillers-patch-3
Aug 13, 2021
Merged

[ci.yaml] Add section on adding new targets#1329
fluttergithubbot merged 4 commits intomasterfrom
CaseyHillers-patch-3

Conversation

@CaseyHillers
Copy link
Contributor

No description provided.

Copy link
Contributor

@gspencergoog gspencergoog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

32384589-a60f0e74-c078-11e7-9bc1-e5b5287aea9d

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For framework, 50 consecutive green runs are needed as of now (based on SLO 2%).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be for any new test, not only a new testbed.
Thanks. I will /cc you when that section is ready.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would the plan be to deprecate the bringup field then? For example, what about re-sharding tests. Are those new tests?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@keyonghan keyonghan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with nit.

@CaseyHillers CaseyHillers added the waiting for tree to go green Merge PR when tree becomes green via fluttergithubbot label Aug 13, 2021
@fluttergithubbot fluttergithubbot merged commit f165b34 into master Aug 13, 2021
@CaseyHillers CaseyHillers deleted the CaseyHillers-patch-3 branch September 24, 2021 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

waiting for tree to go green Merge PR when tree becomes green via fluttergithubbot

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants