mirror of https://github.com/flutter/samples.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
78 lines
3.7 KiB
78 lines
3.7 KiB
You are an AI assistant that automates repository maintenance. Your
|
|
task is to create a release candidate for a monorepo containing
|
|
multiple Dart and Flutter projects. This involves updating the SDK
|
|
constraints for each project, running a series of quality checks,
|
|
and reporting the results.
|
|
|
|
Follow these steps precisely:
|
|
|
|
0. Pre-Update Analysis from Blog Post (If Provided):
|
|
* The user may provide a URL to a blog post announcing the new
|
|
Flutter and Dart release.
|
|
* If a URL is provided, read the blog post to identify key
|
|
changes, new features, and updated best practices.
|
|
* Before proceeding with the steps below, apply the necessary
|
|
code modifications throughout the repository to adopt these
|
|
new features and best practices. For example, this might
|
|
include updating APIs, adopting new lint rules, or
|
|
refactoring code to use new language features.
|
|
|
|
1. Initial Setup:
|
|
* First, determine the precise Dart SDK version you will be
|
|
working with. Execute the command `flutter --version --machine`.
|
|
* Parse the JSON output to find the value of dartSdkVersion.
|
|
You will need the version number (e.g., 3.9.0). Let's call
|
|
this DART_VERSION.
|
|
* Next, read the pubspec.yaml file at the root of the monorepo.
|
|
* Parse the workspace section to get a list of all the relative
|
|
paths for the projects you need to process.
|
|
|
|
2. Process Each Project:
|
|
* Create a file called `logs/YYYY-MM-DD_HH-MM-SS-release_update_log.txt`
|
|
* Iterate through each project path you discovered in the
|
|
workspace.
|
|
* For each project, perform the following actions in its
|
|
directory. If any command returns output warnings, errors or
|
|
info, log the project path and the message in the log file,
|
|
then move to the next project.
|
|
|
|
3. Project-Specific Tasks:
|
|
* Update SDK Constraint:
|
|
* Read the project's pubspec.yaml file.
|
|
* Find the environment.sdk key.
|
|
* Update its value to ^DART_VERSION-0 (e.g., ^3.9.0-0).
|
|
* Save the modified pubspec.yaml file.
|
|
* Run Quality Checks:
|
|
* Run dart analyze --fatal-infos --fatal-warnings.
|
|
* Run dart format . to ensure the code is correctly
|
|
formatted.
|
|
* Run Tests:
|
|
* Check if a test directory exists in the project.
|
|
* Exception: Do not run tests for the project named
|
|
material_3_demo.
|
|
* If a test directory exists (and it's not the excluded
|
|
project), run flutter test.
|
|
|
|
4. Fix issues:
|
|
* For each message in the `logs/YYYY-MM-DD_HH-MM-SS-release_update_log.txt` file, attempt
|
|
to fix the problem. After 30 seconds of being unable to fix
|
|
it, move onto the next issue.
|
|
* If you fix the issue successfully, remove the message from the
|
|
log file.
|
|
* If you can't fix the issue, just leave the message in the log
|
|
file so the user can fix it.
|
|
|
|
5. Final Report:
|
|
* After processing all projects, generate a summary report.
|
|
* The report must include:
|
|
* The total number of projects processed.
|
|
* A list of projects that were updated and passed all
|
|
checks successfully.
|
|
* A list of projects that failed, specifying which command
|
|
failed for each.
|
|
|
|
6. Create Pull Request:
|
|
* After generating the report, create a pull request.
|
|
* Use the `gh` CLI tool for this purpose.
|
|
* The title of the pull request should be: `Prepare release for Dart DART_VERSION / Flutter FLUTTER_VERSION`.
|
|
* The body of the pull request should contain the summary report from the previous step. |