Manual roll Flutter to 58068d8ea4ec (42 revisions)

[ditman]

This PR attempts to roll the master version of Flutter with a small CI tweak.

[ci] Configures split all_packages build

Continuing #7106:

• Makes android_build_all_packages build with JDK17 only, and only a JDK17 project.
• Gets android_build_all_packages_legacy out of bringup.

This should resolve the gradle issues of the "all_packages" app with the latest version of Flutter.

Manual roll Flutter from 5103d75 to 58068d8 (42 revisions)

Same as this roll triggered by the roller:

• Roll Flutter from 5103d7574361 to 58068d8ea4ec (42 revisions) #7110

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or this PR is exempt from CHANGELOG changes.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[stuartmorgan-g]

Unfortunately it looks like the tool still supports a version of Gradle old enough to require 11, so it's no longer possible to test the existing legacy project and the current template on the same setup.

Unless we want to lose some legacy coverage, I think we'll need to split out a new task, making regular build-all and legacy build-all entirely separate (with a TODO to recombine them once we drop the version of Gradle/AGP/etc. that requires 11). @reidbaker do you see any other option?

[ditman]

Yep, I was looking at the legacy version of the app that is now failing.

[gmackall]

That was essentially the motivation for setting up a Java 11 specific shard in flutter/flutter#151433. Sorry, I should have thought about how this would affect the packages legacy test.

[ditman]

@gmackall I think you did exactly what @stuartmorgan is saying, splitting the legacy vs non-legacy builds. I'll prepare something similar for flutter/packages, and see what it looks like!

[ditman]

Linux_android android_build_all_packages_17plus master is a new builder added. it needs to be marked bringup: true

[ditman]

Can't find where the bringup:true build logs are (?)

[stuartmorgan-g]

It's pretty cumbersome to test new builders in advance. In practice, I recommend just adding the new thing in bringup mode and landing it without worrying about whether the script it runs works, and then fixing it in the PR where you take it out of bringup, since then you can just look at the presubmit runs as normal.

[ditman]

Shall we land this @stuartmorgan (after all mac tests stop flaking)? Please, do click the ✅ button!

[stuartmorgan-g]

Sorry, I should have explained better; landing it this way would cause us to lose coverage temporarily. The preferred way to do this is to make a new prequel PR that just adds the new builder, and then once that's in and filtered through infra (it used to be a full day, but now I think it's just a couple of hours?), then you update this PR to take the builder out of bring-up and make the other changes. That way there's no point where we have disabled tests for a while.

[gmackall]

... and then once that's in and filtered through infra (it used to be a full day, but now I think it's just a couple of hours?)

FYI for some reason mine took ~21 hrs to start running automatically, see flutter/flutter#151615. Also they didn't start running until after I had triggered a re-run on one manually, but I have no clue if that was causal 🤷

[ditman]

then you update this PR to take the builder out of bring-up and make the other changes.

Ah, understood, I'll split the CI changes to a prequel PR. See you there!

[ditman]

Here goes @stuartmorgan:

• [ci] Split build_all_packages by JDK version. #7106

I've already done stable because... no need to wait IMO, legacy will continue building with JDK11 and non-legacy will not have any overrides, and we may be able to land both at the same time?

[stuartmorgan-g]

LGTM.

We should do the switch for stable too so that we're not using extra CI cycles to run the legacy build on stable both the old way (combined), and the new way (separated) in bring-up mode. But that can be a follow-up PR if you'd rather.

[ditman]

OK, updated the branch by removing the legacy android build from bringup:true, and making standard build only with JDK17. Also bumped the roll from 20 revisions to something newer (42 revisions).

/cc @stuartmorgan

[ditman]

OK, autosubmit applied, let's go!