Skip to content

Instantly share code, notes, and snippets.

@getsource

getsource/gutenberg_manual_release.md

Last active September 21, 2021 05:20
Show Gist options
  • Save getsource/58dda3fc29d544c1c48c40715ea5e679 to your computer and use it in GitHub Desktop.
Save getsource/58dda3fc29d544c1c48c40715ea5e679 to your computer and use it in GitHub Desktop.
Download ZIP
Resuming a failed Gutenberg ZIP build Notes
Raw
gutenberg_manual_release.md

First, I re-ran the ZIP build. This doesn't bump the version number a second time (which is great), but it does fail with release draft creation.

Here's a message that I sent to Riad to check assumptions (Riad mentioned it was 👍, and this worked when we tried it):

Okay! I’ve been working on the release today.

I dug into the scripts a bit, and it looks like while build-plugin-zip does put new commits on top of the new (pending) Release Notes, it does not seem to handle tagging or updating the changelog following updates in the RC Release / Notes to reflect any changes during RC. So, my current hypothesis is to recreate these conditions: https://github.com/WordPress/gutenberg/blob/trunk/.github/workflows/build-plugin-zip.yml#L226

Then, make a draft release with the appropriate tag, to be generated on publish, and when the “final” release is published, it should kick off this job, which handles the final changelog update: https://github.com/WordPress/gutenberg/blob/trunk/.github/workflows/upload-release-to-plugin-repo.yml#L25

In preparation for this, I ran the changelog script and plugin script locally. I took the “RC updated” parts from the changelog script, and combined those with the newest version of the Release Notes from the RC on GitHub. I did a diff on the unzipped files between the gutenberg.zip file that is inside the gutenberg-plugin.zip file here, and the one I created manually. The binary files were different, but the (diff -r) contents were identical, so I decided to use the gutenberg.zip file that was inside the artifact from GitHub. Then, I created a draft release with all of that [edit: snipped the release draft, since it's not relevant].

To recap, I think that if I publish this, it should kick off the remaining necessary items:

  • Updating the changelog with the appropriate git commits, using the Release Notes in the release draft
  • Tagging 11.5.0
  • Publishing to SVN, after approval inside that job/workflow that is kicked off

I was a little confused that the changelog doesn’t seem to be updated in the artifact on the GitHub release, but that’s also the case for 11.4.0: https://github.com/WordPress/gutenberg/releases/tag/v11.4.0

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