-
Notifications
You must be signed in to change notification settings - Fork 36
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
Add back manual watched branches step #2423
base: unstable
Are you sure you want to change the base?
Conversation
- name: Create Pull Request | ||
uses: peter-evans/create-pull-request@v5 | ||
with: | ||
token: ${{ secrets.SHOPIFY_GH_ACCESS_TOKEN }} | ||
commit-message: 'Add ${{ github.event.inputs.version }} to watched branches' | ||
title: 'Add ${{ github.event.inputs.version }} to watched branches' | ||
body: 'This PR adds the new stable version ${{ github.event.inputs.version }} to the list of watched branches in the changesets-reminder and deploy GitHub actions.' | ||
branch: 'update-watched-branches-${{ github.event.inputs.version }}' | ||
base: '${{ github.event.inputs.version }}' | ||
|
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.
You are removing the PR that gets created, but you still create the branch with the updated GH action files? I'm not sure if I understand correctly.
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.
This is a different PR: to update the Github action yml files. It requires some special permissions in order for a GH app to edit action yml.
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.
I mean that you are still actually updating the files in the workflow, so I think you'd want to remove that too?
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.
Ahh I see what you mean. Yes good call, we don't need that either.
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.
I see a slight problem with this existing workflow. We update the "latest version" variable a little too early in the process. Sometimes a stable version might be cut for days before it actually ships.
Consider that we create a branch for 2025-01 and the "latest version" is updated to that. But, while it is in review a patch was shipped for 2024-10. 2024-10 is still technically the latest version, but it won't get tagged as "latest" because the "latest version" variable has already been updated to 2025-01
.
Maybe we can find another way to identify the "latest" version?
Background
This automation didn't quite work due to missing perms, and it was a bit clunky anyways as the PR this attempted to create needs to be merged before the action runs.
Solution
(Describe your solution, why this approach was chosen, and what the alternatives/impacts may be)
🎩
Checklist