Posts: Automatic WordPress Theme Version with GitHub Actions

One of the things I do on a regular basis involves releasing new versions of custom WordPress themes for the various websites my company maintains. Since we recently migrated everything from Subversion to Git with GitHub, I added a GitHub Action, .github/workflows/release-action.yml, to each theme that automatically packages the themes in a way that WordPress likes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

on:
  push:
    tags:
      - "**"

name: Upload Release Asset

jobs:
  build:
    name: Upload Release Asset
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Get tag
        id: tag
        run: echo "TAG=${GITHUB_REF#refs/tags/}" >> "$GITHUB_OUTPUT"

      - name: Get asset name
        id: asset
        run: echo "ASSET=${{ github.event.repository.name }}-${{ steps.tag.outputs.tag }}.zip" >> "$GITHUB_OUTPUT"

      - name: Build project
        run: git archive --output /tmp/${{ steps.asset.outputs.asset }} --prefix=${{ github.event.repository.name }}/ ${{ steps.tag.outputs.tag }}

      - name: Release
        uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        with:
          files: /tmp/${{ steps.asset.outputs.asset }}

WordPress wants the theme’s folder to be the first thing at the root of the .zip flie, which is accomplished by setting --prefix in git archive.

It took some searching, but Anton wrote a great article on setting up .gitattributes to automatically replace strings in files during the archival process:

1

$ echo style.css export-subst > .gitattributes

Then, in style.css, set the Version: value to $Format:%(describe:tags=true)$:

1
2
3
4
5
6

/*
Theme Name: MyTheme
...
Version: $Format:%(describe:tags=true)$
...
*/

Once this is all done, commit and go into GitHub to create a new release with a new, or existing, tag. After a minute or two, the new file will appear and the tag name you just created will be the new version.

With a little goofing around, I did find that doing a git archive with commits after the latest tag set the version to something like: 0.0.0-2-gce6902f where 0.0.0 is the tag, 2 is the number of commits after the tag, g might mean “git”, and ce6902f is the commit hash.