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

Bootstrap an automation tool #15699

Merged
merged 23 commits into from May 24, 2019
Merged

Bootstrap an automation tool #15699

merged 23 commits into from May 24, 2019

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented May 17, 2019

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:

  • Checking the status of the branch and local changes.
  • Choosing the right version for the RC.
  • Creating the release branch.
  • Performing the bump (updated the files).
  • Committing the version bump changes.
  • Building the plugin zip.
  • Pushing the release branch and the git tag.
  • Creating a github release with the changelog and the zip.
  • Cherry-picking the version bump to master.

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 separate package.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.

@youknowriad youknowriad added [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. [Type] Project Management Meta-issues related to project management of Gutenberg labels May 17, 2019
@youknowriad youknowriad self-assigned this May 17, 2019
@youknowriad youknowriad added [Type] Build Tooling Issues or PRs related to build tooling and removed [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. labels May 17, 2019
Copy link
Member

@gziolo gziolo left a 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 :)

bin/commander.js Outdated Show resolved Hide resolved
@youknowriad
Copy link
Contributor Author

I updated this, this covers the whole RC process now 🎉
I added testing instructions to be able to test this without touching this repo

@youknowriad
Copy link
Contributor Author

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:

  • Make it easy to develop and try the tool
  • Avoid conflicts with existing uncommited changes... the repo is kept untouched
  • Makes it easy to extract as a separate tool later.

@youknowriad
Copy link
Contributor Author

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)

@youknowriad youknowriad requested a review from a team May 21, 2019 08:56
git clean -xdf
else
error "Fair enough; aborting. Tidy up your repo and try again. 🙂"
if [ -z "$NO_CHECKS" ]; then
Copy link
Member

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.

bin/commander.js Outdated Show resolved Hide resolved
const packageLockPath = workingDirectoryPath + '/package-lock.json';
const pluginFilePath = workingDirectoryPath + '/gutenberg.php';
const gutenbergZipPath = workingDirectoryPath + '/gutenberg.zip';
const repoOwner = 'WordPress';
Copy link
Member

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?

Suggested change
const repoOwner = 'WordPress';
const { REPO_OWNER: repoOwner = 'WordPress' } = process.env;

Copy link
Contributor Author

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 Show resolved Hide resolved
bin/commander.js Outdated Show resolved Hide resolved
bin/commander.js Outdated Show resolved Hide resolved
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)',
Copy link
Member

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

Suggested change
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.',

Copy link
Member

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.

Copy link
Contributor Author

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.

bin/commander.js Outdated Show resolved Hide resolved
bin/commander.js Outdated Show resolved Hide resolved
bin/commander.js Outdated Show resolved Hide resolved
youknowriad and others added 8 commits May 23, 2019 23:08
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
@youknowriad
Copy link
Contributor Author

This should be ready, I'm going to merge this later today to be able to use it for the next release.

Copy link
Member

@gziolo gziolo left a 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 🎉

@gziolo
Copy link
Member

gziolo commented May 24, 2019

By the way, let's add a note in release notes to make sure people use it :)

@gziolo gziolo mentioned this pull request May 24, 2019
@youknowriad
Copy link
Contributor Author

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.

@youknowriad youknowriad merged commit e81f191 into master May 24, 2019
@youknowriad youknowriad deleted the add/automation-tool branch May 24, 2019 16:21
@youknowriad youknowriad added this to the 5.8 (Gutenberg) milestone May 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Build Tooling Issues or PRs related to build tooling [Type] Project Management Meta-issues related to project management of Gutenberg
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants