Update the release process #2799
Conversation
So GitHub knows what should be removed from the final zip
This create a new tag when pushing to trunk. Then we use that tag to create the release
|
Noting that the unit test error is likely unrelated to the changes here, but otherwise still worth resolving separately to ensure those stay working. |
| run: | | ||
| npm ci | ||
| npm run build | ||
|
|
||
| - name: WordPress Plugin Deploy | ||
| if: "! github.event.release.prerelease" |
There was a problem hiding this comment.
Since we're not including prerelease in line 8 above is this check necessary?
There was a problem hiding this comment.
Actually, line 8 is for draft/published, and this line is for pre-releases (alpha, beta, etc.) or "official" releases. We probably should move this check to be appended to line 8 but that would require some additional research.
CONTRIBUTING.md
Outdated
| 1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/elasticpress/. This may take a few minutes. | ||
| 1. [Check the _Build and Tag_ action](https://github.com/10up/ElasticPress/actions/workflows/build-and-tag.yml): a new tag named with the version number should've been created. It should contain all the built assets. | ||
| 1. Release: Create a [new release](https://github.com/10up/elasticpress/releases/new), naming the release with the new version number, and targeting the tag created in the previous step. Paste the release changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the [milestone](https://github.com/10up/elasticpress/milestone/#?closed=1). | ||
| 1. SVN: Wait for the [GitHub Action](https://github.com/10up/ElasticPress/actions?query=workflow%3A%22Deploy+to+WordPress.org%22) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes. |
There was a problem hiding this comment.
Which one, @jeffpaul? 41 will be once we merge and run this once. The second one (line 43) was already there (and also seems to work)
There was a problem hiding this comment.
Yes 43 resolves but that's the action from 3 years ago, seems like you'd want to link to the new one as https://github.com/10up/ElasticPress/actions/workflows/push-deploy.yml?query=workflow%3A%22Deploy+to+WordPress.org%22 yeah?
There was a problem hiding this comment.
:doh: of course. Changed it now.
| - name: Setup | ||
| run: 'echo "VERSION=$(grep -Po ''\"version\": \"[0-9\\.]+\"'' package.json | grep -Po ''[0-9\\.]+'')" >> $GITHUB_ENV' | ||
|
|
||
| - name: Tag |
There was a problem hiding this comment.
Are we certain we want to automate tagging on a push to trunk? Will want to admit this opens us to some human error where an incomplete or inadvertent push to trunk will result in a tag that may not have been intended (or if the version number wasn't bumped correctly the tagging will presumably fail since the tag number already exists).
There was a problem hiding this comment.
Actually, the more I think about this, the more it makes sense to me. If someone inadvertently pushes to trunk and:
- The version number is not updated: it will likely fail and do nothing
- If the version is updated, then we've already merged the changelog, etc. If we are at that point and inadvertently pushes to trunk, we'd expect something to fail anyway.
We could mirror trunk to a stable branch and tag from that but I don't know if we would win much with an additional step. Happy to discuss it.
| 1. SVN: Wait for the [GitHub Action](https://github.com/10up/ElasticPress/actions?query=workflow%3A%22Deploy+to+WordPress.org%22) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes. | ||
| 1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/elasticpress/. This may take a few minutes. | ||
| 1. [Check the _Build and Tag_ action](https://github.com/10up/ElasticPress/actions/workflows/build-and-tag.yml): a new tag named with the version number should've been created. It should contain all the built assets. | ||
| 1. Release: Create a [new release](https://github.com/10up/elasticpress/releases/new), naming the release with the new version number, and targeting the tag created in the previous step. Paste the release changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the [milestone](https://github.com/10up/elasticpress/milestone/#?closed=1). |
There was a problem hiding this comment.
I've not tried things this way, so curious if selecting that tag will already set the branch to trunk or if that's still needed to be called out in this step?
There was a problem hiding this comment.
Yeah, that was something interesting. When you select a tag that already exists, GitHub won't ask you anything about the branch.
Co-authored-by: jeffpaul <jeffpaul@users.noreply.github.com>
Co-authored-by: jeffpaul <jeffpaul@users.noreply.github.com>
Description of the Change
This PR changes the release process so we can distribute the plugin via composer without needing WPackagist.
Closes #2727
Verification Process
Tested in https://github.com/felipeelia/ElasticPress/releases/tag/4.1.0 with success.
Changelog Entry
Changed: The plugin is now available via Composer without any additional steps required.
Credits
Props @felipeelia @jeffpaul @johnbillion