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

Update automation #812

Merged
merged 6 commits into from Jan 14, 2022
Merged

Update automation #812

merged 6 commits into from Jan 14, 2022

Conversation

felipesu19
Copy link
Contributor

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

  1. Add automation to the relevant repos that detects the new pr after the script creates them, runs an action and makes the changes based on that
  2. Automatically commits that change to the pr and sends a message to the pr creator. This should reduce the burden to just having to run three deploys (two actually, based on point 3)
  3. I'd also like to get pages.github.com to somehow listen to changes via a github action, rather than rebuilding itself every 6 hours as originally suggested. However if that's too finicky (and based on preliminary investigation it may well be), we should just get it auto-rebuilding. If we do that we can cut the part of the automation that concerns itself with that repo.
  4. Finally, the automation could use some hardening, the script as it exists has no retry logic and no real failure handling.

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.

@felipesu19 felipesu19 requested a review from a team January 12, 2022 20:21
script/release Show resolved Hide resolved
script/release Outdated Show resolved Hide resolved
script/release Outdated Show resolved Hide resolved
@felipesu19
Copy link
Contributor Author

Gonna merge this in, will open a new pr with the tagging bit of the work

@felipesu19 felipesu19 merged commit de2f6b4 into master Jan 14, 2022
@felipesu19 felipesu19 deleted the release-updates branch January 14, 2022 21:42
Copy link
Contributor

@parkr parkr left a 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
Copy link
Contributor

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'
Copy link
Contributor

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.

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.

None yet

4 participants