-
Notifications
You must be signed in to change notification settings - Fork 355
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
Update automation #812
Update automation #812
Conversation
Co-authored-by: Tommy Byrd <[email protected]>
Gonna merge this in, will open a new pr with the tagging bit of the work |
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.
Some quick comments for your next PR!
|
||
# check that gh is installed and logged in | ||
|
||
gh auth status -h github.com |
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.
Since this is before the set -e
, if it fails it won't stop the script from running.
# first get the sha of main for each repo | ||
|
||
gh_pages_sha = gh api repos/github/pages/git/refs/heads/master | jq '. | .object.sha' | ||
jekyll_sha = gh api repos/actions/jekyll-build-pages/git/refs/heads/main | jq '. | .object.sha' |
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.
What shell are you using? I thought you'd need backticks to execute commands and return their output.
This change seeks to ensure we mantain gem version parity as per this issue and the subsequent card , we really need to ensure we update the gem version in at least three places.
This is the first pass at automating that change, via adding an automated tag release via the gh cli and creating new prs in the relevant repos so we know what work needs to be done, which will fire whenever anyone runs the release script
As part of the cleanup task I'd like to
This is ready for a first pass. I've manually tested this by running through the command flow starting with line 46 in the script/release file (with some manual interpolations), as part of the work I'm going to create a new release which will test things end to end and let me clean up the dependent repos, but i'm going to tackle #3 first.
Feedback on the idea, the implementation, and the general direction of this work. Its possible that point #1 is too much work for how often we release new gems, and we should focus on 2 and 3.