[web] increase number of shards. sync engine web tests same as flutter repo

[nturgut]

increase number of shards. sync engine web tests same as flutter repo tests. Similar framework PR: flutter/flutter#62623

Related Issues

flutter/flutter#62510

Tests

Tests run on cirrus ci.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the [contributor guide] and followed the process outlined there for submitting PRs.
• I signed the [CLA].
• I read and followed the [C++, Objective-C, Java style guides] for the engine.
• I read the [tree hygiene] wiki page, which explains my responsibilities.
• I updated/added relevant documentation.
• All existing and new tests are passing.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

No.

[nturgut]

@Piinks Do you know what GOLD_SERVICE_ACCOUNT is used for, this was added to web shards for flutter/flutter but was missing on the engine side, so I'm also adding this value here.

[mdebbar]

If the tests are passing without it, it's probably not needed here.

[nturgut]

Yeah, seems like they failed. so I'll try another run without it.

[godofredoc]

What are we missing to migrate this tests to LUCI?

[mdebbar]

LGTM

[nturgut]

/cc @christopherfujino We have an interesting example of bandwidth consumption here :) I'm changing a configuration on .cirrus.yml file but all LUCI tests are still triggered. Where should I change, for these type of changes to not trigger LUCI?

[christopherfujino]

/cc @christopherfujino We have an interesting example of bandwidth consumption here :) I'm changing a configuration on .cirrus.yml file but all LUCI tests are still triggered. Where should I change, for these type of changes to not trigger LUCI?

Scheduling of LUCI try jobs happens here https://github.com/flutter/cocoon/blob/master/app_dart/lib/src/request_handlers/github_webhook.dart#L162. We currently don't look at all at which files are affected. You could double check, but at first glance it doesn't look like the PR webhook provides any information on the affected files https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads#pull_request or https://docs.github.com/en/rest/reference/pulls. It looks like to conditionally trigger try jobs, we'd need to do an additional request (or use the graphql api) and pull in all the commits of the PR, and then all the files.

[godofredoc]

It looks like to conditionally trigger try jobs,
That's something that I forgot to add to the migration design doc, the initial pull request contains the list of files affected in the PR but we still need to expand the json/yaml file to include the filters.

[nturgut]

I'm merging this PR since tests run without issues. Flutter framework tree is closed now, therefore I'll merge the framework PR later.

I'll keep an eye on this Cirrus tests to see if they reduced the flakiness.

[liyuqian]

@nturgut : engine Cirrus tests run in our own GKE cluster and there's a different resource limit than the framework Cirrus tests. Adding ~10 shards per commit will exhaust our resources and make engine commit presubmit tests to have a long pending time. Are we seeing similar flaky results (flutter/flutter#62510) in engine Cirrus tests before this PR, or is there another critical reason to add those ~10 shards? ? CC @yjbanov who originally helped bring the shard number down.

[nturgut]

@nturgut : engine Cirrus tests run in our own GKE cluster and there's a different resource limit than the framework Cirrus tests. Adding ~10 shards per commit will exhaust our resources and make engine commit presubmit tests to have a long pending time. Are we seeing similar flaky results (flutter/flutter#62510) in engine Cirrus tests before this PR, or is there another critical reason to add those ~10 shards? ? CC @yjbanov who originally helped bring the shard number down.

@tvolkert Increasing the shard number helped me to avoid the issue flutter/flutter#62510 However it looks like it exhaust the Cirrus limits. What should I do? Since #62510 is a P2, I don't have any other solutions at hand.

[nturgut]

@nturgut : engine Cirrus tests run in our own GKE cluster and there's a different resource limit than the framework Cirrus tests. Adding ~10 shards per commit will exhaust our resources and make engine commit presubmit tests to have a long pending time. Are we seeing similar flaky results (flutter/flutter#62510) in engine Cirrus tests before this PR, or is there another critical reason to add those ~10 shards? ? CC @yjbanov who originally helped bring the shard number down.

@yjbanov suggested Dart team to increase the number of shards for the same issue: flutter/flutter#61462

[liyuqian]

Discussed with @nturgut offline. We're only exhausting the engine Cirrus limits here so having a high shard number in the framework Cirrus tests to solve P2 flutter/flutter#62510 is still fine. We're going to bring down the engine shard number to 8 to see if we can strike a balance between flakiness and resource limits. After all, it seems that the engine tests aren't that flaky even if the shard number was 4.