Latest Posts

Categories

Categories

Automating plugin releases to WordPress.org using GitLab CI

I got started in WordPress development as many do, by writing a plugin. It, along with nearly a dozen others that I’ve released in intervening years, don’t require much attention, so I’ve generally neglected even the most-basic of maintenance: confirming each is compatible with the latest WordPress release and updating the readme accordingly. I’ve felt guilty about this for some time now, but it wasn’t until this weekend that that guilt compelled me to action.

I’ve been on a bit of a GitLab-CI kick recently, and I’d started on an automated release process some months ago, but my attention shifted. With the 5.2 release imminent, and thanks to Helen Hou-Sandi’s work on a GitHub Action with the same intent, I finally put together a CI-based process to release an update to WordPress.org’s plugins’ SVN.

The script and documentation are found at https://git.ethitter.com/open-source/wp-org-plugin-deploy. It supports releasing new versions (SVN tags) as well as updating existing tags, so it can be used to update the WordPress-compatibility data stored in the plugin. The static assets used on WordPress.org can also be sourced from a designated directory in the git repository.

For ease of maintenance, the script is sourced from the main repository (via a CDN) each time GitLab CI runs the deploy job, otherwise each update to the deploy process would require an update to each plugin that uses it.

Releases can be sourced from branches or tags. In my case, I use tags to mark releases, following the format v0.1, which allows all release tags to be protected using a v* wildcard rule. To allow deploy-related issues to be found early, the script is run as part of non-release pipelines, as it exits before the commit step when not working with the configured release reference.