Skip to content
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

Open
wants to merge 3 commits into
base: unstable
Choose a base branch
from

Conversation

MitchLillie
Copy link
Contributor

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

  • I have 🎩'd these changes
  • I have updated relevant documentation

Comment on lines -36 to -45
- 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 }}'

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@jamesvidler jamesvidler left a 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants