search

Flow-Launcher / Flow.Launcher.PluginsManifest

Community-made plugins and submissions
36 stars 107 forks source link

Publish workflow clobbers existing release #406

Open cspotcode opened 1 week ago

cspotcode commented 1 week ago

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:

  1. Change version number in plugin.json to 1.0.0
  2. Commit, git tag v1.0.0, and git push --tags
  3. Workflow runs, reads version from plugin.json, builds, uploads zip to newly-created Release 1.0.0
  4. Start working on new features for v2
  5. git commit -m 'WIP new features, kinda works, breaks sometimes' && git push
  6. Workflow runs again! This is bad
  7. Workflow runs, reads version from plugin.json -- is still 1.0.0 -- builds, overwrites zip on Release 1.0.0!

Now, when someone tries to install 1.0.0 of the plugin, they will download a broken version with "WIP new feature" code.

jjw24 commented 1 week 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?

cspotcode commented 1 week ago

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.

cspotcode commented 1 week ago

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.

https://github.com/cspotcode/Flow.Launcher.Plugin.EdgeWorkspaces/blob/7e1c081995fc84678e8cfc6d2a8db13dbd8f9744/.github/workflows/Publish%20Release.yml#L5-L6