GitHub Actions: Build Plugin zip, create release draft, attach zip #19626

ockham · 2020-01-14T13:32:47Z

Description

First stab at writing a GitHub action to build Gutenberg upon creating a tag that starts with v, and creating a draft release with the build attached to it.

Based on build-plugin-zip.sh.

Using https://github.com/actions/create-release and https://github.com/actions/upload-release-asset.

How has this been tested?

Make sure you have your own fork of the Gutenberg repo, and that you've added it locally as a remote (E.g. git remote add ockham git@github.com:ockham/gutenberg.git if your GH username is ockham 🙂 ).
Check out this PR's branch, and push the contents to your fork's master branch (you can reset later):

git push ockham add/build-github-action:master

Add a version tag (must start with v), e.g. git tag v9.2.0-rc.1.
Push that tag to your fork: git push --tags ockham.
Go to the 'Actions' tab of your fork's GH page (e.g. https://github.com/ockham/gutenberg/actions).
Locate the action whose description reads "Build Gutenberg and upload to Draft Release", and click on it.
It should take less than 10 minutes to build the plugin zip. You can watch that page as the action progresses.
Eventually, a release draft will be created, and the plugin zip will be attached. You'll find it under 'Releases' (e.g. https://github.com/ockham/gutenberg/releases)

(I've used my Gutenberg fork as an example, you can see the relevant action and release drafts from previous runs there.)

Types of changes

Build tools automation

TODO

Add npm module cache. See e.g. unit test action

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.
I've included developer documentation if appropriate.
I've updated all React Native files affected by any refactorings/renamings in this PR. .

/cc @sirreal @gziolo

gziolo · 2020-01-14T13:59:54Z

@youknowriad is the best person to share feedback and follow along 😄

talldan · 2020-01-16T04:38:46Z

I think the only way to test is to merge this, and then create a tag starting in v. Since the action only creates a release draft, that shouldn't be too much of a problem, since we can delete it after.

I think you could probably test it on a fork.

youknowriad · 2020-01-16T09:05:15Z

How is this different from our release script and what benefit do we get compared to it?

ockham · 2020-01-16T12:13:38Z

How is this different from our release script

You mean build-plugin-zip.sh? I based it on that script, so it's not very different. It requires fewer cleanup steps tho, since it runs in a throwaway CI environment.

and what benefit do we get compared to it?

More automation -- it would automatically create release zips once a tag is added, rather than requiring people to spend time running the script locally, blocking them from coding. This means that releases become cheaper, and we might e.g. experiment with alpha releases at some point (which might come in handy for hosted versions of Gutenberg 😬). It also helps define a reproducible environment for builds.

Finally, if this proves valuable, we might look into automating other parts of the release process. There's e.g. a GitHub action to publish plugins to the WP.org plugin SVN repo, or we might be able to automate release of @wordpress/ npms.

ockham · 2020-01-16T12:13:57Z

I think the only way to test is to merge this, and then create a tag starting in v. Since the action only creates a release draft, that shouldn't be too much of a problem, since we can delete it after.

I think you could probably test it on a fork.

Ah, good thinking! I might give that a try 🙂

youknowriad · 2020-01-16T12:31:56Z

No, I meant compared to our current ./bin/commender.js rc/./bin/commender.js stable, that's a script that bumbs the Gutenberg version in the required files, tag the release, create the zip, uploads the Gutenberg release and changelog and also handle the SVN releasing.

I'm really glad that you're putting effort to try to help them automate things and I'd love to see more automation in flows we didn't explore yet but It does feel like we're already pretty well covered with the release tool. https://github.com/WordPress/gutenberg/blob/master/docs/contributors/release.md

github-actions · 2020-10-13T15:06:25Z

Size Change: 0 B

Total Size: 1.21 MB

ℹ️ View Unchanged

Filename	Size	Change
`build/a11y/index.js`	1.14 kB	0 B
`build/annotations/index.js`	3.78 kB	0 B
`build/api-fetch/index.js`	3.45 kB	0 B
`build/autop/index.js`	2.84 kB	0 B
`build/blob/index.js`	665 B	0 B
`build/block-directory/index.js`	8.72 kB	0 B
`build/block-directory/style-rtl.css`	943 B	0 B
`build/block-directory/style.css`	942 B	0 B
`build/block-editor/index.js`	130 kB	0 B
`build/block-editor/style-rtl.css`	11.1 kB	0 B
`build/block-editor/style.css`	11.1 kB	0 B
`build/block-library/editor-rtl.css`	8.98 kB	0 B
`build/block-library/editor.css`	8.98 kB	0 B
`build/block-library/index.js`	146 kB	0 B
`build/block-library/style-rtl.css`	7.83 kB	0 B
`build/block-library/style.css`	7.84 kB	0 B
`build/block-library/theme-rtl.css`	837 B	0 B
`build/block-library/theme.css`	838 B	0 B
`build/block-serialization-default-parser/index.js`	1.88 kB	0 B
`build/block-serialization-spec-parser/index.js`	3.1 kB	0 B
`build/blocks/index.js`	48.1 kB	0 B
`build/components/index.js`	172 kB	0 B
`build/components/style-rtl.css`	15.2 kB	0 B
`build/components/style.css`	15.2 kB	0 B
`build/compose/index.js`	9.81 kB	0 B
`build/core-data/index.js`	12.3 kB	0 B
`build/data-controls/index.js`	772 B	0 B
`build/data/index.js`	8.77 kB	0 B
`build/date/index.js`	31.8 kB	0 B
`build/deprecated/index.js`	768 B	0 B
`build/dom-ready/index.js`	571 B	0 B
`build/dom/index.js`	4.46 kB	0 B
`build/edit-navigation/index.js`	11.2 kB	0 B
`build/edit-navigation/style-rtl.css`	881 B	0 B
`build/edit-navigation/style.css`	885 B	0 B
`build/edit-post/index.js`	306 kB	0 B
`build/edit-post/style-rtl.css`	6.38 kB	0 B
`build/edit-post/style.css`	6.37 kB	0 B
`build/edit-site/index.js`	22.1 kB	0 B
`build/edit-site/style-rtl.css`	3.86 kB	0 B
`build/edit-site/style.css`	3.85 kB	0 B
`build/edit-widgets/index.js`	26.4 kB	0 B
`build/edit-widgets/style-rtl.css`	3.1 kB	0 B
`build/edit-widgets/style.css`	3.1 kB	0 B
`build/editor/editor-styles-rtl.css`	480 B	0 B
`build/editor/editor-styles.css`	482 B	0 B
`build/editor/index.js`	43.1 kB	0 B
`build/editor/style-rtl.css`	3.85 kB	0 B
`build/editor/style.css`	3.85 kB	0 B
`build/element/index.js`	4.65 kB	0 B
`build/escape-html/index.js`	735 B	0 B
`build/format-library/index.js`	7.7 kB	0 B
`build/format-library/style-rtl.css`	547 B	0 B
`build/format-library/style.css`	548 B	0 B
`build/hooks/index.js`	2.13 kB	0 B
`build/html-entities/index.js`	623 B	0 B
`build/i18n/index.js`	3.57 kB	0 B
`build/is-shallow-equal/index.js`	712 B	0 B
`build/keyboard-shortcuts/index.js`	2.52 kB	0 B
`build/keycodes/index.js`	1.94 kB	0 B
`build/list-reusable-blocks/index.js`	3.11 kB	0 B
`build/list-reusable-blocks/style-rtl.css`	476 B	0 B
`build/list-reusable-blocks/style.css`	476 B	0 B
`build/media-utils/index.js`	5.34 kB	0 B
`build/notices/index.js`	1.79 kB	0 B
`build/nux/index.js`	3.42 kB	0 B
`build/nux/style-rtl.css`	671 B	0 B
`build/nux/style.css`	668 B	0 B
`build/plugins/index.js`	2.56 kB	0 B
`build/primitives/index.js`	1.43 kB	0 B
`build/priority-queue/index.js`	791 B	0 B
`build/redux-routine/index.js`	2.85 kB	0 B
`build/reusable-blocks/index.js`	3.06 kB	0 B
`build/rich-text/index.js`	13.2 kB	0 B
`build/server-side-render/index.js`	2.77 kB	0 B
`build/shortcode/index.js`	1.69 kB	0 B
`build/token-list/index.js`	1.27 kB	0 B
`build/url/index.js`	4.06 kB	0 B
`build/viewport/index.js`	1.84 kB	0 B
`build/warning/index.js`	1.14 kB	0 B
`build/wordcount/index.js`	1.22 kB	0 B

_{compressed-size-action}

ockham · 2020-10-14T20:00:04Z

Pushing the code from this branch to my fork of the repo, I finally got this to work 🎉

Did the following locally:

git tag v9.3.0-rc.1
git push --tags ockham

This triggered the action to build a Gutenberg zip, create a Release Draft, and attach the zip to it in under 10 minutes.

I now have to check if the zip is complete and works.

ockham · 2020-10-14T20:11:46Z

I now have to check if the zip is complete and works.

The vendor/ folder (and contents) is missing, seems like the $vendor_scripts var isn't set properly.

ockham · 2020-10-15T14:16:40Z

I've worked a bit more on this and tested it on my repo fork (thanks @talldan for the suggestion)! I've updated the PR desc with reproducible testing instructions. This seems to be working quite smoothely now -- please give it a try!

Would we be open to reconsider merging this PR? I think we could still keep the ./bin/commander.js command for branching/tagging etc, but could offload the actual plugin build to this GH action. Maybe only for the RC at first, and later also for stable versions -- we can add another GH action that uploads the plugin to the WP.org SVN repo upon publishing a stable version (there's some precedent for this).

Overall, I hope that eventually we'd end up with a setup where releasing the plugin doesn't require cloning the GB repo into a temporary directory plus the SVN plugin repo onto one's own machine, but to offload all that to GH. I hope that this will help make the release process (feel) more lightweight, and potentially allow us doing more RCs (and possibly nightlies, at some point) to aid with testing on a variety of setups (e.g. big multi-user WP instances) prior to releases.

youknowriad · 2020-10-15T14:31:28Z

Overall, I hope that eventually we'd end up with a setup where releasing the plugin doesn't require cloning the GB repo into a temporary directory plus the SVN plugin repo onto one's own machine, but to offload all that to GH.

I think that's a great goal but for me it feels like we're recreating the script why not just provide a -no-interactive option in bin/plugin/cli.js and just run it as a github action?

ockham · 2020-10-15T20:11:10Z

Overall, I hope that eventually we'd end up with a setup where releasing the plugin doesn't require cloning the GB repo into a temporary directory plus the SVN plugin repo onto one's own machine, but to offload all that to GH.

I think that's a great goal but for me it feels like we're recreating the script why not just provide a -no-interactive option in bin/plugin/cli.js and just run it as a github action?

Thanks Riad!

🤔 It seemed to make sense to me to have the build plugin action only create the zip and attach it to a draft release, but wait for the user to actually publish -- to give the user a final chance to revise the release. (I'd probably remove the CLI step where the user is supposed to fill in the changelog -- they can do that in the GH release UI instead; mostly so we don't duplicate interactive steps.) I'd then couple the SVN upload to the publishing of the GH release, i.e. when things are 'final'. To the user, that should all feel fairly transparent and consistent: they'll first get a draft release to fill in and publish, and once that's done, they'll automatically get the plugin uploaded to SVN.

Curious to hear your thoughts!

ockham · 2020-10-15T21:05:50Z

it feels like we're recreating the script why not just provide a -no-interactive option in bin/plugin/cli.js and just run it as a github action?

One more note here, I think we have somewhat of a separation of concerns already that will apply quite well to what we're doing here:

The GH action I'm adding in this PR only builds the zip -- it corresponds directly to build-plugin-zip.sh (which it invokes) rather than any of the plugin/cli.js commands (since it doesn't come with the repo cloning overhead, and doesn't involve any of the branching/tagging.
The GH action I'm thinking of for when a release is published will correspond to runSvnRepositoryCheckoutStep and runUpdateTrunkContentStep.
The remainder of the script will be mostly about the branching/tagging/versioning, up until the point where the newly created tag is pushed to the repo, from where the action will take over.

youknowriad · 2020-10-16T07:30:12Z

For me, I still feel these intermediary steps will just add friction over what we currently have. Meaning, we should click a single "button" to release everything and I shouldn't be asking myself if I should create a tag from master or a tag from a release branch or anything. I can just say "release major", "release patch" and that should be enough.

ockham · 2020-10-16T09:58:28Z

For me, I still feel these intermediary steps will just add friction over what we currently have. Meaning, we should click a single "button" to release everything and I shouldn't be asking myself if I should create a tag from master or a tag from a release branch or anything. I can just say "release major", "release patch" and that should be enough.

Not sure I'm following 🤔 That part of the script could stay the same, you could continue to ./bin/commander.js rc and ./bin/commander.js stable; it's just that once the tag is created and pushed (by that script!), the zip is built by GH rather than locally. One of the benefits would be that the user can then return to work on other things in their locally checked out repo more quickly, rather than to wait for the build to finish.

The goal is definitely not to add friction here 💯

Hope I've been reading you correctly, please LMK if I haven't!

youknowriad · 2020-10-16T12:24:10Z

Not sure I'm following 🤔 That part of the script could stay the same, you could continue to ./bin/commander.js rc and ./bin/commander.js stable; it's just that once the tag is created and pushed (by that script!), the zip is built by GH rather than locally.

There's something I'm missing here, the only places where we create tags is in these commands, we don't do that manually and these commands do need the zip as well for the SVN part. so I'm not really sure it makes sense to separate these two flows?

fullofcaffeine · 2020-10-30T02:39:46Z

This seems to work well 👍🏻 ✅

Action output: https://github.com/fullofcaffeine/gutenberg/runs/1330020144
Release: https://github.com/fullofcaffeine/gutenberg/releases/

I can't approve but I'll be following the discussion. It's not entirely clear to me what are the main benefits over the CLI approach, other than moving the UI to a GUI :) but I haven't read all the text yet.

bph · 2020-11-04T19:06:13Z

I have been working on the other end of a similar process with the goal to release a daily Gutenberg
Zip form Master

Now @ockham, your PR helps with automating the build process and push it to my fork. Thank you!

ockham · 2020-12-03T22:21:56Z

Superseded by #27488.

ockham added [Status] In Progress Tracking issues with work in progress [Type] Build Tooling Issues or PRs related to build tooling labels Jan 14, 2020

ockham self-assigned this Jan 14, 2020

ockham removed the [Status] In Progress Tracking issues with work in progress label Jan 15, 2020

ockham marked this pull request as ready for review January 15, 2020 12:19

ockham requested review from karmatosed, mapk and youknowriad as code owners January 15, 2020 12:19

ockham requested review from sirreal, aduth and gziolo January 15, 2020 12:19

ockham force-pushed the add/build-github-action branch from 8e81494 to f798fcc Compare October 13, 2020 14:57

ockham force-pushed the add/build-github-action branch 2 times, most recently from 8202794 to 95c70c7 Compare October 15, 2020 11:16

ockham added 20 commits October 29, 2020 12:07

Name the asset gutenberg.zip

ea6d3d6

Remove verbose comment

bc481d6

Set production constants

4d242d2

Use npm install rather than ci

364a00e

Add logic to download vendor scripts

f4f9bd5

Include $vendor_scripts in zip

9ecb254

Single quotes

2d4baec

Update build files

53e0873

Set vendor_scripts differently

7f2538a

Entire lib dir

759ca4f

Remove PUPPETEER_SKIP_CHROMIUM_DOWNLOAD

652f2f6

Use new syntax for env vars

fd9f5c0

Fix vendor_scripts

ad013ff

Newlines between steps

928b5f4

Don't include 'Release' in release name

1a1c73a

Run shell script

713c2de

Try setting release name

8a795db

Escape var name

46a9cdf

Use an output instead of an env

b8caf98

Add node modules cache, setup node 12

8b62586

ockham force-pushed the add/build-github-action branch from 931af11 to 8b62586 Compare October 29, 2020 11:07

ockham changed the title ~~Build: Gutenberg build GitHub Action~~ GitHub Actions: Build Plugin zip, create release draft, attach zip Nov 5, 2020

This was referenced Nov 5, 2020

GitHub Actions: Build Plugin zip, store as artifact on every PR #26746

Merged

Lazy Images: Use calypso-build to build Automattic/jetpack#17571

Merged

ockham mentioned this pull request Dec 3, 2020

GitHub Actions: Create Release Draft when tagging version #27488

Merged

ockham closed this Dec 3, 2020

ockham deleted the add/build-github-action branch December 3, 2020 22:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Actions: Build Plugin zip, create release draft, attach zip #19626

GitHub Actions: Build Plugin zip, create release draft, attach zip #19626

ockham commented Jan 14, 2020 •

edited

Loading

gziolo commented Jan 14, 2020

talldan commented Jan 16, 2020

youknowriad commented Jan 16, 2020

ockham commented Jan 16, 2020

ockham commented Jan 16, 2020

youknowriad commented Jan 16, 2020

github-actions bot commented Oct 13, 2020 •

edited

Loading

ockham commented Oct 14, 2020

ockham commented Oct 14, 2020

ockham commented Oct 15, 2020

youknowriad commented Oct 15, 2020

ockham commented Oct 15, 2020

ockham commented Oct 15, 2020

youknowriad commented Oct 16, 2020

ockham commented Oct 16, 2020

youknowriad commented Oct 16, 2020

fullofcaffeine commented Oct 30, 2020

bph commented Nov 4, 2020

ockham commented Dec 3, 2020

GitHub Actions: Build Plugin zip, create release draft, attach zip #19626

GitHub Actions: Build Plugin zip, create release draft, attach zip #19626

Conversation

ockham commented Jan 14, 2020 • edited Loading

Description

How has this been tested?

Types of changes

TODO

Checklist:

gziolo commented Jan 14, 2020

talldan commented Jan 16, 2020

youknowriad commented Jan 16, 2020

ockham commented Jan 16, 2020

ockham commented Jan 16, 2020

youknowriad commented Jan 16, 2020

github-actions bot commented Oct 13, 2020 • edited Loading

ockham commented Oct 14, 2020

ockham commented Oct 14, 2020

ockham commented Oct 15, 2020

youknowriad commented Oct 15, 2020

ockham commented Oct 15, 2020

ockham commented Oct 15, 2020

youknowriad commented Oct 16, 2020

ockham commented Oct 16, 2020

youknowriad commented Oct 16, 2020

fullofcaffeine commented Oct 30, 2020

bph commented Nov 4, 2020

ockham commented Dec 3, 2020

ockham commented Jan 14, 2020 •

edited

Loading

github-actions bot commented Oct 13, 2020 •

edited

Loading