Automating plugin releases to 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’s plugins’ SVN.

The script and documentation are found at 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 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.

An example of the script in use is at, which produced this changeset:

While the GitLab project is the canonical repository, it is mirrored to GitHub at