[tool] Support alternate repositories#11743
Conversation
|
More work will be needed to make this work for a reo without Flutter, and also to make it publishable again, but I'll do those in separate PRs. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request centralizes repository-specific configuration into a new .repo_tool_config.yaml file, replacing several separate configuration files. It introduces a tool_config.dart utility to manage these settings, enabling the tooling to support multiple Flutter team repositories by parameterizing the repository name, SDK constraints, and dependency allowances. Feedback focuses on making the configuration parsing more robust by replacing unsafe type casts with defensive type checking and addressing potential issues with the global configuration cache in multi-repository scenarios.
tarrinneal
left a comment
tarrinneal
left a comment
There was a problem hiding this comment.
one small philosophic discussion then it's good to land.
| @@ -1,5 +1,5 @@ | |||
| name: flutter_plugin_tools | |||
| description: Productivity and CI utils for flutter/packages | |||
| description: Productivity and CI utils for Flutter team package repositories. | |||
There was a problem hiding this comment.
is the team here necessary? can this not be used by non-team repos?
There was a problem hiding this comment.
In theory they could, but I suspect that when, e.g., license-check failed all their code for not being Copyright 2013 The Flutter Authors, or validate failed packages for not having an issue link pointing to flutter/flutter they would be unhappy.
Once upon a time the package was intended to be a more general-purpose tool, but when we stopped publishing it, we stopped distinguishing between "the Flutter team wants to enforce this" and "this is probably generally a good idea", and so the tool is no longer generically useful.
We could decide to go back to a generic tool someday, but it would require non-trivial additional work, and we'd want to evaluate whether that would actually be useful, or whether we should instead contribute to (and partially replace our tooling with) an existing tool like melos or mono_repo.
| The examples below assume they are being run from the repository root, but | ||
| the script works from anywhere. If you develop in flutter/packages frequently, | ||
| it may be useful to make an alias for | ||
| the script works from anywhere. If you develop in a Flutter team package |
stuartmorgan-g
added
the
autosubmit
…#186950) flutter/packages@3754d04...69cf959 2026-05-21 stuartmorgan@google.com [tool] Support alternate repositories (flutter/packages#11743) 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
2 participants
Moves some hard-code repo information, such as the expected source link base in pubspec.yaml, to repo-level configuration. Also consolidates the
tool_configdirectory introduced in the last refactoring into a single.repo_tool_config.yamlto consolidate things and better match most other Dart/Flutter config systems (analyzer, project pubspec, LUCI config, etc.)Fixes flutter/flutter#185364