WIP - Implement code freeze mechanism at autosubmit

[Piinks]

This adds the ability to implement a code freeze in Flutter repositories based on PR labels or specific code paths.
In preparation for decoupling, we will be putting a code freeze in place for material and cupertino. This will not happen for a few weeks.

We discussed a few ways to do this:

1. (⭐ This approach) Add to autosubmit check.
   • Various validations are already completed in the process of executing autosubmit. This PR adds this functionality so that if a PR changes the material or cupertino libraries cannot be merged. More details on implementation below.
2. Add an analyzer lint in flutter/flutter, this would be a failing pre-submit check in CI that would prevent changes from landing in cupertino or material.
   • This would not be as robust, as we expect there will still be several open PRs at the time we freeze the code. These PRs would need to rebase in order to pick up the new check, which would leave open the opportunity for changes to land if they have not rebased.
   • Further, the generic code freeze mechanism can be used again in the future for other potential code freezes in whatever repo we might need to freeze.
3. Close all PRs changing material or cupertino, auto-close new PRs.
   • To continue to foster collaboration and contribution, we have decided we will leave existing PRs open during the freeze to allow authors to continue to make progress, and then port over their changes to the new libraries when they are ready to accept changes.
   • Closing PRs like this could also discourage contributors from coming back later.

Overview of the preferred approach here

• All code freeze settings are managed in auto_submit/lib/configuration/code_freeze.yaml. This file maps repository slugs to specific "frozen" labels and file paths.
• Freezes can be targeted at specific labels (e.g., f: material design) or specific directories (e.g., packages/flutter/lib/src/material/). Because it's repo-specific, a freeze on flutter/flutter will not affect flutter/packages unless explicitly configured.
• A new CodeFreeze validation has been added to the standard autosubmit pipeline. When a PR matches any freeze criteria:
  • The autosubmit label is automatically removed.
  • A comment is posted to the PR explaining that the merge is blocked due to the active code freeze for the matched labels or paths.

To modify the code freeze in the future, simply update the auto_submit/lib/configuration/code_freeze.yaml file.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read the Flutter Style Guide recently, and have followed its advice.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• 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.

[jtmcdole]

Excellent place for JsonSerializable:

final yamlMap = loadYaml(yamlString) as YamlMap;
return YourJsonSerializable.fromJson(Map<String, dynamic>.from(yamlMap));

[jtmcdole]

This only happens at boot time - what do you think about using something like DynamicConfig?

code: https://github.com/flutter/cocoon/blob/main/app_dart/lib/src/service/flags/dynamic_config.dart

e.g. usage (the fetcher reads from github HEAD every 5 minutes, so no code push needed):

cocoon/app_dart/bin/gae_server.dart

Lines 48 to 50 in ccfc427

	final configUpdater = DynamicConfigUpdater();
	final dynamicConfig = await configUpdater.fetchDynamicConfig();
	final config = Config(

There's no file reading there either; we use build hooks to codify the config at compile time.

[Piinks]

Updated, is this more what you were thinking? :)

[jtmcdole]

More to think about: how many PRs are merged with the merge button vs using autosubmit? A label that only blocks autosubmit will not prevent PRs from landing. I do like the frozen paths, but honestly - a workflow that fails if the path is modified would ensure you do not land anything since it will be "failing" for those paths. Autosubmit should respect that.

[Piinks]

More to think about: how many PRs are merged with the merge button vs using autosubmit? A label that only blocks autosubmit will not prevent PRs from landing. I do like the frozen paths, but honestly - a workflow that fails if the path is modified would ensure you do not land anything since it will be "failing" for those paths. Autosubmit should respect that.

Yeah, definitely room for folks to still sneak in, even though we don't want people to use the merge button. Do you mean we should maybe do both this and the presubmit check from the analyzer?