Update ci for + releases - #12419
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the regular expressions for enabled release branches in .ci.yaml to support optional pre-release and build metadata suffixes. The review feedback points out that the regex character class [\w.] should be updated to [\w.-] to correctly support hyphens, which are valid in SemVer 2.0.0.
| - release-go_router-\d+\.\d+\.\d+(?:-[\w.]+)?(?:\+[\w.]+)? | ||
| - release-cupertino_ui-\d+\.\d+\.\d+(?:-[\w.]+)?(?:\+[\w.]+)? | ||
| - release-material_ui-\d+\.\d+\.\d+(?:-[\w.]+)?(?:\+[\w.]+)? |
There was a problem hiding this comment.
The regular expression [\w.] matches alphanumeric characters, underscores, and dots, but it does not match hyphens (-). According to the SemVer 2.0.0 specification, both pre-release identifiers and build metadata can contain hyphens (e.g., 1.0.0-alpha-1 or 1.0.0+build-123).\n\nTo fully support valid SemVer release branch names, the character class should be updated to include hyphens, i.e., [\w.-]. Note that the hyphen should be placed at the end of the character class to avoid being interpreted as a range.
- release-go_router-\d+\.\d+\.\d+(?:-[\w.-]+)?(?:\+[\w.-]+)?\n - release-cupertino_ui-\d+\.\d+\.\d+(?:-[\w.-]+)?(?:\+[\w.-]+)?\n - release-material_ui-\d+\.\d+\.\d+(?:-[\w.-]+)?(?:\+[\w.-]+)?
stuartmorgan-g
left a comment
There was a problem hiding this comment.
LGTM.
In practice the only thing we ever actually use in this repo is +[\d]+, but there's not much risk of false positives here given the prefixes
|
autosubmit label was removed for flutter/packages/12419, because - The status or check suite Dashboard Checks has failed. Please fix the issues identified (or deflake) before re-applying this label. |
…r#190923) flutter/packages@1861b68...aaaf246 2026-08-10 jmccandless@google.com [cupertino_ui] Main example (flutter/packages#12380) 2026-08-10 katelovett@google.com Update ci for + releases (flutter/packages#12419) 2026-08-10 engine-flutter-autoroll@skia.org Manual roll Flutter from b766512 to 27b0988 (29 revisions) (flutter/packages#12420) 2026-08-10 engine-flutter-autoroll@skia.org Manual roll Flutter from e52f01c to b766512 (42 revisions) (flutter/packages#12406) 2026-08-10 41930132+hellohuanlin@users.noreply.github.com [camera]fix test flake due to expectation fulfilled before flag is toggled (flutter/packages#12400) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-packages-flutter-autoroll Please CC flutter-ecosystem@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Updates the
enabled_branchesregex patterns in.ci.yamlto support SemVer release branch names with optional pre-release tags (e.g.,-dev.1) and build metadata suffixes (e.g.,+1).Previously,
enabled_branchesused the strict patternrelease-<package>-\d+\.\d+\.\d+.When release branches were created with build metadata suffixes (e.g.,
release-material_ui-0.0.3+1), Cocoon CI failed validation with:Blocked PRs:
Updated the regex for release branches to
release-<package>-\d+\.\d+\.\d+(?:-[\w.]+)?(?:\+[\w.]+)?, allowing valid SemVer pre-release and build metadata identifiers while maintaining strict matching against non-version branch names.Pattern Verification Examples
release-material_ui-0.0.3release-material_ui-0.0.3+1release-material_ui-0.0.3-dev.1+2release-material_ui-invalid-branchPre-Review Checklist
[shared_preferences]///).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-assistbot 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
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2