Skip to content

Standardize package targeting in plugin tools #83413

Closed
flutter/plugins
#4290
@stuartmorgan-g

Description

@stuartmorgan-g

The plugin repo tooling is currently inconsistent about how its commands are targetted:

  1. Many support a common set of flags:
    • --plugins to target a specific list (should be changed to --packages ideally, since we use this tooling for flutter/packages too)
    • --run-on-changed-packages to only run on changed packages (or in the case of tooling or CI changes, all packages), which we use for presubmit
    • No arguments to run on everything, which we use for post-submit
  2. Some, like version-check, always run on exactly the set of changed pubspec files
  3. publish has its own --package, which it uses instead of --plugins
  4. license-check always runs on every file

Also, we have --exclude as a standard option applying to type 1, but xctest has its own --skip which I believe does exactly the same thing and is jus an accident.

The inconsistencies make it harder to use the tooling, and more importantly harder to reason about changes. E.g., we want it to be the case that if a new rule is added to the script that the PR that does so finds and fixes violations, rather than them being submarine issues that break the next PR that happens to touch those plugins. Things that use option 2 don't have that property, and it's not even obvious that that's the case during review.

Option 4 is a feature for the license check since it's cheap and we always want to make sure everything is correct there, but everything else should be standardized on option 1.

Metadata

Metadata

Labels

P3Issues that are less important to the Flutter projectc: contributor-productivityTeam-specific productivity, code health, technical debt.p: toolingAffects the flutter_plugin_tools packagepackageflutter/packages repository. See also p: labels.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions