Open cspotcode opened 1 month ago
That's a very good point, I have been meaning to update the docs/plugin to use and show how this plugin's workflow handles publishes https://github.com/jjw24/Wox.Plugin.GoogleSearch/blob/master/.github/workflows/build.yml. Essentially this workflow does a diff of the latest releases version and the version in the master branch.
Since I don't have time yet to do this, would you be keen to help update it?
I wish I could, but I'm swamped at work. Thank you for linking a nicer alternative though, hopefully this ticket can serve as a useful reference until the docs can be updated.
For mine, I've adjusted the triggers so it only runs when I push tags of the form v*
. This has an advantage over the diff approach: it can be retriggered by re-pushing the tag, if the first one fails. Sometimes I push the tag, realize I messed up, make new commits, force-push the tag.
It's also simpler to set up:
on:
push:
tags: ['v*']
...although I should add validation that the git tag matches the value from plugin.json
, which adds complexity.
The sample Github Actions workflow will clobber your existing Github Release far too easily if you let it. This means you'll publish a potentially broken version of your plugin to the latest release, which breaks for anyone who tries to install it.
The docs: https://www.flowlauncher.com/docs/#/py-setup-project?id=_1-add-github-workflow Recommend using this workflow: https://github.com/Flow-Launcher/Flow.Launcher.Plugin.HelloWorldPython/blob/main/.github/workflows/Publish%20Release.yml
The problem is, it runs for every push to
main
, including the commit immediately after you published a new version. Imagine this scenario:plugin.json
to1.0.0
git tag v1.0.0
, andgit push --tags
git commit -m 'WIP new features, kinda works, breaks sometimes' && git push
Now, when someone tries to install 1.0.0 of the plugin, they will download a broken version with "WIP new feature" code.