Unable to get my build chain to publish

Development
1

I’m trying to get my github build chain working for my Venom plugin, the one referenced in this post:

It builds all four platforms just fine. But I cannot get it to publish - it always says the publish job was skipped. I gave the plugin version “v2.1.0”, and also tagged the commit the same. So I expected the job to publish a release, but no such luck.

Anyone have any pointers as to where I have gone wrong?

2

The action does not care about the version inside the json file. It instead looks at the tags on the commit, i believe. If the commit has a tag that starts with v, it will publish. I think.

3

That is what I thought, but my commit version does begin with “v”. I don’t know the syntax of the file, but in my ignorance it appears that later on in the publish job that I copied it also checks that the json version matches the commit version. But that is true in my case as well. So I am stumped.

4

Did you create an annotated tag (git tag -a -m “v2.1.0” v2.1.0) or just a bare one?

5

I am not very familiar with git terminology, but I believe it is annotated. I created the tag locally with GitHub Desktop, then pushed to the server. I can see the tag on the GitHub server.

1 Like
6

It’s because the tag shoud be named “v2.1.0” which you have done correctly, but the plugin version in the manifest should be named “2.1.0” NOT with a leading “v”.

If you look in the workflow file here’s the relevant block:

- name: Check if plugin version matches tag
run: |
  pluginversion=`jq -r '.version' plugin.json`
  if [ "v$pluginversion" != "${{ env.CI_REF_NAME }}" ]; then
    echo "Plugin version from plugin.json 'v$pluginversion' doesn't match with tag version '${{ env.CI_REF_NAME }}'"
    exit 1
  fi

The specific part is "v$pluginversion". Here you can see that it reads the plugin version, which should be “2.1.0”, then prepends it with a “v” and then compares it with the tag.

3 Likes
7

Thanks Lars - I have since removed the “v” from my plugin.json version, but still no luck.

I’ve looked at some Surge build runs, and I see that the initial modify-plugin-version: job skips the run step if the tag begins with “V”. But when I run it does not skip. I restructured the run step a bit to give it a name and to put the if: at the top of the step. But I believe it should logically be the same, and a prior run failed in the same way before I made that change.

The other major difference is the publish job - Surge obviously runs the job, and mine skips the job.

I don’t understand why mine behaves differently.

I’m assuming the build action creates the release from scratch. Or are you supposed to create the release placeholder first, and then run the build action? Obviously I am doing something wrong.

8

What’s your repo? Maybe I can peek

But yeah surge creates for any tag marked v2.1.0 etc when I push

9

Venom plugin

10

Oh i think it doesn’t work because you manually trigger as opposed to trigger on tag and so it is not built for a tag reason

Add that or that and workflow dispatch and push a tag v2.1.4

Here’s my steps

1 Like
11

Thanks Paul.

I was really hoping to only run on demand. But I guess I can make this work

12

Success! Thanks again.

13

If you want it to only run on demand and to always make a release, you can look at the changes I made to mine: PathSetModules/build-plugin.yml at main · patheros/PathSetModules · GitHub

Line 2 only contains workflow_dispatch Line 86 is commented out.

2 Likes
14

I built my release actions to trigger on the creation of a release, rather than on a tagged commit. When I started with github actions, it wasn’t really feasible to do actions on demand, so triggering on release creation seemed the best compromise.

I create the release, and then a few minutes later, the built packages get added to it.

15

Sounds good. Could you post a link to the workflow file?

16

It’s probably very out of date now. It doesn’t use the official tool chain.

1 Like