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

Create a production-ready release artifact from master branch builds #6285

Open
danielbachhuber opened this Issue Apr 19, 2018 · 8 comments

Comments

Projects
None yet
5 participants
@danielbachhuber
Member

danielbachhuber commented Apr 19, 2018

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:

image

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

@danielbachhuber danielbachhuber added this to the Bonus Features milestone Apr 19, 2018

@davisshaver

This comment has been minimized.

Show comment
Hide comment
@davisshaver

davisshaver Apr 19, 2018

Contributor

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.

Contributor

davisshaver commented Apr 19, 2018

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

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Apr 19, 2018

Member

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.

Member

danielbachhuber commented Apr 19, 2018

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 comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Sep 27, 2018

Member

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.
Member

danielbachhuber commented Sep 27, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tofumatt

tofumatt Sep 27, 2018

Member

Any interest in formalizing this in some way?

1,000% yes from me 😄

Member

tofumatt commented Sep 27, 2018

Any interest in formalizing this in some way?

1,000% yes from me 😄

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Sep 27, 2018

Member

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.

Member

danielbachhuber commented Sep 27, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tofumatt

tofumatt Sep 27, 2018

Member

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.

Member

tofumatt commented Sep 27, 2018

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

This comment has been minimized.

Show comment
Hide comment
@chrisvanpatten

chrisvanpatten Sep 27, 2018

Contributor

(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.)

Contributor

chrisvanpatten commented Sep 27, 2018

(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

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Oct 2, 2018

Member

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

image

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

Member

danielbachhuber commented Oct 2, 2018

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

image

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

@mtias mtias added Future and removed Future labels Oct 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment