[batch-release] Step3: Adds github action to create a PR to sync changes on the go_router release branch back to the main branch #10393
Conversation
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
| # Fetch all history for all branches | ||
| fetch-depth: 0 | ||
|
|
||
| - name: Create Sync Pull Request |
There was a problem hiding this comment.
There is existing github action
- name: Create Pull Request
uses: peter-evans/create-pull-request@v7
with:
token: ${{ secrets.GITHUB_TOKEN }}
commit-message: "...."
title: "...."
body: "...."
branch: release
base: main
hannah-hyj
changed the title
| on: | ||
| push: | ||
| branches: | ||
| - 'release' |
There was a problem hiding this comment.
Wait, I'm confused about the flow again. How can there be a single release branch that multiple packages are doing releases from while still supporting the async PR approval model? The whole point of using a branch for a release is that the branch can be a snapshot of the state that we want to release for a given package version.
@chunhtai is there a diagram or flow chart in a doc somewhere that shows the final plan for how the branches will work?
There was a problem hiding this comment.
ah, I forgot about the race condition if we use single branch, where the other package may have merged and brought in new changes.
yeah.. in that case you would need separate release branch for each packages. let me revise the doc a bit and update the issues
There was a problem hiding this comment.
There was a problem hiding this comment.
Review here is still blocked on resolution to the question raised in that doc.
hannah-hyj
changed the title
| @@ -0,0 +1,26 @@ | |||
| name: "Sync Release to Main" | |||
There was a problem hiding this comment.
If this action is now specific to go-router, then the file name and action name will need to reflect that.
There was a problem hiding this comment.
This doesn't have to be go-router specific if we use wild card matching
There was a problem hiding this comment.
or can just be
on:
push:
branches:
- 'release-go-router'
- 'release-material'
- 'release-cupertino'
Though I think wild card will be easier if we can handle the security aspect of people may create random branches on flutter/packages
| @@ -0,0 +1,26 @@ | |||
| name: "Sync Release to Main" | |||
There was a problem hiding this comment.
This doesn't have to be go-router specific if we use wild card matching
| on: | ||
| push: | ||
| branches: | ||
| - 'release-go-router' |
There was a problem hiding this comment.
though do we have any restriction for team-member creating branches in the flutter/package? if so we would have to manually add each package here
There was a problem hiding this comment.
though do we have any restriction for team-member creating branches in the flutter/package?
We don't; I believe that was turned on for flutter/flutter recently, but we intentionally didn't turn it on for flutter/packages since most clients aren't cloning this repository, so extra branches have relatively little downside, and we sometimes use that feature.
There was a problem hiding this comment.
i see, in that case we should hard code these branches for now, either way this file can be generic for all package.
| @@ -0,0 +1,26 @@ | |||
| name: "Sync Release to Main" | |||
There was a problem hiding this comment.
or can just be
on:
push:
branches:
- 'release-go-router'
- 'release-material'
- 'release-cupertino'
Though I think wild card will be easier if we can handle the security aspect of people may create random branches on flutter/packages
3 participants
issue: #177110
Everytime something is pushed to the release branch, sync it back to the main branch.
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