mirror of https://github.com/flutter/samples.git
Eric Windmill
4 weeks ago
parent
04e6e73b26
commit
8b8727bb9d
@ -1,46 +0,0 @@
|
||||
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:
|
||||
|
||||
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 '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 `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.
|
||||
@ -0,0 +1,10 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"dart": {
|
||||
"command": "dart",
|
||||
"args": [
|
||||
"mcp-server"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,78 @@
|
||||
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.
|
||||
@ -1,8 +0,0 @@
|
||||
# Stale Code Log
|
||||
|
||||
This file tracks sample projects that have not received meaningful code updates in over a year.
|
||||
|
||||
| Sample Name | Last Commit Author | Date of Last Commit |
|
||||
|-------------|--------------------|---------------------|
|
||||
| code_sharing/shared | Kevin Moore | Thu Oct 20 09:00:41 2022 |
|
||||
| asset_transformation | Andrew Kolos | Tue May 14 08:42:21 2024 |
|
||||
Loading…
Reference in new issue