-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Bootstrap an automation tool #15699
Bootstrap an automation tool #15699
Conversation
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 cool. Let's merge it and start using it and refine as we discover issues :)
I updated this, this covers the whole RC process now 🎉 |
I noticed while developping this that it's hard to develop the script on the repo and have the script perform commits, releases.. on the same repo. In the last commit, I'm using a separate clone of the repository to perform all the release taks. This has a few of advantages:
|
Anyone willing to give this a try before I move forward and merge it. It should be easy to test on a fork (see testing instructions) |
git clean -xdf | ||
else | ||
error "Fair enough; aborting. Tidy up your repo and try again. 🙂" | ||
if [ -z "$NO_CHECKS" ]; then |
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.
Aside: I'm happy to see this change, and had planned to propose similarly, for benefit of gutenberg.run, where I implemented my own custom version of this script to skip these steps, as they'd been slow to execute in containers, and unnecessary for fresh clones.
const packageLockPath = workingDirectoryPath + '/package-lock.json'; | ||
const pluginFilePath = workingDirectoryPath + '/gutenberg.php'; | ||
const gutenbergZipPath = workingDirectoryPath + '/gutenberg.zip'; | ||
const repoOwner = 'WordPress'; |
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.
Per testing instructions, if part of the point of making this a variable is for configurability, should we open up that configurability as an environment variable?
const repoOwner = 'WordPress'; | |
const { REPO_OWNER: repoOwner = 'WordPress' } = process.env; |
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'm hesitant to introduce this now. I think there's value in it but down the road, we're going to touch SVN repos as well. Will we need an env variable for that repo as well. Ideally we'd have a consistent pattern to ease testing in fake environments. Maybe a single config file?
bin/commander.js
Outdated
const { token } = await inquirer.prompt( [ { | ||
type: 'input', | ||
name: 'token', | ||
message: 'Please provide a Github personal authentication token. (Navigate to ' + success( 'https://github.com/settings/tokens' ) + ' to create one with admin:org, repo and write:packages rights)', |
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 can simplify this further by specifying scopes as query argument:
https://github.com/settings/tokens/new?scopes=repo,admin:org,write:packages
message: 'Please provide a Github personal authentication token. (Navigate to ' + success( 'https://github.com/settings/tokens' ) + ' to create one with admin:org, repo and write:packages rights)', | |
message: 'Please provide a GitHub personal authentication token. Navigate to ' + success( 'https://github.com/settings/tokens/new?scopes=repo,admin:org,write:packages' ) + ' to create one.', |
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.
Are we using the packages feature? 🤔
At some point, it would be nice to remember this, or use credentials from OS. I think I've used (or authored?) packages before which integrate with the OS password vault to retrieve credentials.
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 don't think we are, but I think for the "roles", GitHub considers the releases as packages. Without that right, I had errors.
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
This should be ready, I'm going to merge this later today to be able to use it for the next release. |
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.
It works like a charm. I was able to go through all steps. This is the result of my test run:
https://github.com/gziolo/gutenberg/releases/tag/v5.8.0-rc.1
This is pure gold. I love all the bits of this script. My favorite part is that it operates on fresh clone of the repo so it doesn't remove my project configuration in IDE 🎉
By the way, let's add a note in release notes to make sure people use it :) |
I'll do it once we figure out the whole process. |
We start to have a lot of manual tasks when performing plugin releases, npm releases, changelogs,... and all of these flows. I think we should invest some time automating these to avoid mistakes and I think it could be a huge gain in time ultimately.
To do so, I'd like us to change the "manual" required work from performing the task to checking that everything went well and confirming using an interactive CLI tool. This is obviously not an easy tool to build with all these flows but I'm confident it will bring more confidence and time gains.
I started looking at the plugin RC release process and bootstrapped a
release-plugin-rc
CLI tool. This flow is complex, this PR implements the following flow:The process is covered entirely, we could push it a bit further and include slack notifications.
This tool uses under the hood some npm utilities (commander, inquirer, chalk, simplegit), this adds a small burden when performing
npm install
on the project so I considered whether this should be a separatepackage.json
/tool independent from the repository that you can bootstrap when needed. (This could be an easy follow-up if ever this grows too much).Thoughts?
Testing instructions
The best way to try this locally without touching the official repo is to:
1- Checkout this branch.
2- Change the value of the
repoOwner
variable (set your username instead of WordPress).3- have a fork the Gutenberg repository.
4- Run the command
bin/commander.js rc
.At that point, your forked repo should be updated with the release.