-
Notifications
You must be signed in to change notification settings - Fork 3.6k
[batch-release] Step2 : Publish packages from the release branch #10459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
new api lint lint update tests Update publish_command_test.dart Update publish_command_test.dart 2 2 Update publish_command_test.dart lint Update publish_command.dart Update release_from_batch_release.yml Update release.yml clean up code Update publish_command.dart 1
| release: | ||
| uses: ./.github/workflows/release.yml | ||
| with: | ||
| publish-args: '--all-changed --batch-release --base-sha=HEAD~ --skip-confirmation --remote=origin' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feels like this can be a boolean?
| # Declare default permissions as read only. | ||
| permissions: read-all | ||
|
|
||
| jobs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we were to reuse a common release sub workflow for both release from branches and release from main in the future, we should refactor it now for release from branches.
because we have to make sure the sub workflow works before using it for release from main, so we might as well do it now for release from branches.
| isBatchReleasePackage = ciConfig.isBatchRelease; | ||
| } | ||
| } catch (e) { | ||
| printError('Could not parse ci_config.yaml for $packageName: $e'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should throw tool exit in this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also should add a test for this
chunhtai
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly looks good now except for the comment
Co-authored-by: chunhtai <[email protected]>
chunhtai
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| 'Release all packages that contains pubspec changes at the current commit compares to the base-sha.\n' | ||
| 'The --packages option is ignored if this is on.', | ||
| ); | ||
| argParser.addFlag( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flags are booleans; they don't take arguments. Options take arguments. This is why 30+ unit tests are failing.
| // the opt-in flag and that the package name matches the branch suffix. | ||
| // Example: branch "release-go_router" matches package "go_router". | ||
| if (!isBatchReleasePackage || | ||
| batchReleaseBranchName != 'release-$packageName') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the code taking a branch name, but then ignoring it to use a constructed name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is taking a branch name and compare if it's a exact match with the package name.
For example , the branch name is "release-go_router",
and we get the package name with changed pubspecs, and we compare if "release-go_router" and "go_router" is a match.
script/tool/test/util.dart
Outdated
| String? version = '0.0.1', | ||
| String flutterConstraint = _defaultFlutterConstraint, | ||
| String dartConstraint = _defaultDartConstraint, | ||
| bool? batchRelease, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nullable booleans need clear documentation about what null means. Here it seems to be that null means there's no CI config, while false means that it explicitly has a config that doesn't do batch release.
Although that seems like more than a documentation problem; this won't scale to adding other CI config options in the future. I think it would be much clearer to have a separate helper method to add a ci_config.yaml to a RepositoryPackage, and then that can take a bunch of arguments for what settings to use, without those implicitly controlling the creation of the file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Also, that will resolve the problem that this is forcing all tests to creating plugins, even if they only want to test non-plugin packages.)
issue: flutter/flutter#176944
Add a batch Release Flag in the publish command.
The main branch will only publish packages that are opted out of batch release.
The release branch will only publish packages that are opted into batch release.
Pre-Review Checklist
[shared_preferences]pubspec.yamlwith an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under1.CHANGELOG.mdto add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under1.///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2 ↩3