samuelmeuli / action-electron-builder

:electron: GitHub Action for building and releasing Electron apps
MIT License
658 stars 201 forks source link

Publish workflow #4

Closed baruchiro closed 4 years ago

baruchiro commented 4 years ago

Hi, first thanks a lot for this Action!

I have a question, I'm pretty sure that part of it is about Github Releases, but I sure you can help me, and learn how we using your action.

So, I'm playing with your action, and like your example, I trigger the Release pipeline when a new tag start with v added.

But even if there is such tag, say v1.2.3, the Github Release will be 0.0.1, from the package.json.

My logic is like this:

  1. There is no meaning when setting a tag without updating the version in package.json (Even more - it's misleading).
  2. If we trigger the Release by pushing to master, until the version in package.json will change, all the releases files will upload to the current release.
  3. Github Releases are actually Git tags, so if you using this action, you don't need to use Tags to control the releases, but you control the releases tags by the version in package,json and the action.

The only problem is how to auto avoiding publish to release that no draft (I mean, you continue pushing to the master with 0.0.1 in package.json, so you have a Draft Release number 0.0.1, that always updated with your master. Then you apply the Github Release 0.0.1, and pushing to the master again, without updating the package.json to the next version. Now you have a public release that should not change, but each push to the master change it).

What do you think?

Sorry about my English.

samuelmeuli commented 4 years ago

Hi @baruchiro,

Thanks for the feedback!

But even if there is such tag, say v1.2.3, the Github Release will be 0.0.1, from the package.json.

Make sure you bump the version in package.json as well, it should match your Git tag. See this part of the README.

There is no meaning when setting a tag without updating the version in package.json

That's true. And I think it makes sense that way. I cannot think of a situation in which you'd want the versions in package.json and the tag to differ.

If we trigger the Release by pushing to master, until the version in package.json will change, all the releases files will upload to the current release.

That depends on how you're using the action. If you use the workflow I suggest in the README, the action will be triggered on every commit (i.e. it will build the app), but it will only upload assets if a valid tag is found (i.e. it will release the app):

          # If the commit is tagged with a version (e.g. "v1.0.0"),
          # release the app after building
          release: ${{ startsWith(github.ref, 'refs/tags/v') }}

Github Releases are actually Git tags, so if you using this action, you don't need to use Tags to control the releases, but you control the releases tags by the version in package,json and the action.

You're right, the action could also parse the package.json file instead and create a new release whenever the version has changed. But I think the current workflow makes sense: You bump the version, tag the commit, and electron-builder will turn the tag into a release.

I'm aware that this action enforces quite a strict release workflow. If you can think of a way to improve it, I'm always open to suggestions 🙂