Gutenberg: Create a production-ready release artifact from master branch builds

[danielbachhuber]

To better automate the release process, it would be helpful to create a production-ready release artifact from master branch builds.

More specifically, what I mean by "production-ready release artifact" is a copy of the plugin that's ready for commit to WordPress.org.

If we include this in the master branch build process, a secondary benefit is that we'll always have a user-installable test version.

To offer some ideas... I use DeployHQ for client projects to push a copy of the built code to my staging server. At the end of the push, DeployHQ runs wp dist-archive <plugin-name> (docs) to create an installable ZIP minus development cruft (e.g. package.json). On the staging server, I have download-plugin-build running so the client can download a copy of the latest build:

Another idea: we can use Circle CI exclusively for this process, to avoid consuming Travis builds.

[davisshaver]

Good idea. Alternatively this might be done with a build branch if we didn't want to include the zip in the main codebase. node_modules, test, and phpunit could also be omitted.

[danielbachhuber]

Alternatively this might be done with a build branch if we didn't want to include the zip in the main codebase.

To clarify, the zip wouldn't ever be committed, only created during the CI build and then delivered to some destination.

[danielbachhuber]

This came up in the #hosting-community chat yesterday: https://wordpress.slack.com/archives/C3D6T7F8Q/p1537981948000100

I've written a script to run on a six hour cron on my server: https://gist.github.com/danielbachhuber/f5fc9caa03541698949af81e42130ad1

The nightly build can be installed with:

wp plugin install https://builds.danielbachhuber.com/gutenberg-nightly.zip --force

@WordPress/gutenberg-core Any interest in formalizing this in some way? I see a few different options:

1. Replicate this script on WordPress.org infrastructure, and offer gutenberg-nightly.zip off the WordPress.org domain.
2. Enhance this script to commit the build artifact to https://plugins.svn.wordpress.org/gutenberg/trunk, such that trunk always mirrors master.
3. Use CircleCI to create build artifacts for both master and branches (#9712), and then deploy the build artifacts to S3 or similar. The advantage of using CircleCI is that it can be decoupled from Travis. CircleCI also has some built in build artifact features.

[tofumatt]

Any interest in formalizing this in some way?

1,000% yes from me 😄

[danielbachhuber]

Some conversation in #meta today: https://wordpress.slack.com/archives/C02QB8GMM/p1538053117000100

Notably, from @Otto42 (specific to option 2):

By and large I would be against this. There's nothing wrong with us generally using trunk versions of plugins on .org, but if you're going to potentially pollute that trunk with bleeding edge nightlies without human intervention, then I'd be more inclined to stop doing that and to pin gutenberg to the latest release version instead.
The important thing about code we run on .org is that it must work. If it stops, for any reason, then we have to go in and intervene. Making a system where pieces are changing automatically is difficult and error prone. I like the SVN being used because it means that somebody must manually upload the files to there. More eyeballs is a good thing. It's unlikely somebody will upload broken code to the SVN, or if they do, then we have a historical record of who did what, when, and why.

And from @Clorith:

I wonder about the value in doing this _now_ though, with yesterdays talks, it seems liek they want to get it into core sooner rather than later (paraphrasing), which means it'll be in the WP nightly any way?
And also those that end up running nightlies that have an even higher "break factor" than a normal release, if it's readily available on .org via the plugin page

I'd be fine with leaving my current implementation (https://builds.danielbachhuber.com/gutenberg-nightly.zip) running for the next couple of months if we don't want to invest more time into it.

[tofumatt]

Oh, right, I'm sorry, I should have clarified:

I would consider SVN plugin trunk for releases and RCs, not development versions too. I don't see much value in pushing master to there except for translators. Maybe that's worthwhile? Dunno.

But offering a "nightly" .zip to the world in an automated fashion would be ace.

[chrisvanpatten]

(On a related token, if there was a nightly easily available it would be super cool to see a nightly-based frontenberg somewhere in the wild for quickly testing the state of things without needing to spin up an environment.)

[danielbachhuber]

I made a build process enhancement to: 1) bump to next version, 2) append -alpha-<short-hash>:

I've also blogged it here: https://danielbachhuber.com/2018/10/02/gutenberg-nightly-build/

[ellatrix]

I would love this. This could also help with git bisecting.