[ci] Adds more ci checks for batch release file integrity

[chunhtai]

also opts in go_router

Pre-Review 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.
• 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 I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

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

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[gemini-code-assist]

Code Review

This pull request enhances the CI checks for batch release file integrity by adding validation for workflow files, triggers, and branches for packages that opt into batch releases. It also opts in the go_router package to this new system. The changes are well-tested and improve the reliability of the release process. I have a few suggestions to further improve the robustness of the new checks and clean up a minor code duplication issue in the tests.

[gemini-code-assist]

This error printing loop is redundant. The PackageLoopingCommand framework, which is the caller of runForPackage, is responsible for iterating over the returned errors and printing them. Including this loop will cause error messages to be printed twice. These lines can be removed.

[gemini-code-assist]

Using String.contains to check for the workflow trigger is brittle. It could incorrectly match a commented-out line or fail to match if the formatting (e.g., quoting) is different. To make this check more robust, you should parse the YAML and inspect the branches list. This would be consistent with how the package-specific workflow file is validated elsewhere in this command.

    final YamlMap? yaml = loadYaml(content) as YamlMap?;
    final on = yaml?['on'] as YamlMap?;
    final push = on?['push'] as YamlMap?;
    final branches = push?['branches'] as YamlList?;
    final bool hasTrigger = branches?.contains('release-$packageName') ?? false;

[stuartmorgan-g]

What's the goal of putting this in a changelog and versioning it? There's no functionality change for clients here.

[chunhtai]

This is for me to test the feature to ensure the entire workflow works, or do you think we should wait until we have a contribution?

[stuartmorgan-g]

https://github.com/flutter/flutter/blob/master/docs/ecosystem/release/README.md needs to be updated to describe batched release, and this error message should link to the relevant part of that updated page that explains the process of adopting batched releases (workflow file to add, workflow file to update to list the new package name, config file to add, etc.)

[stuartmorgan-g]

If there's a large block of code all to do one conceptual task, that should be extracted to a clearly named and documented helper.

In general, any time code has the pattern:

// Description of what the following code does
<lots of code>

// Description of a new thing that the next section of code does
<lots of code>

...

That's a code smell that there should be smaller functions to do the steps.