Fix release pipeline

[scinos]

Comes from the discussion in #157. I open this issue to centralize the discussion

Issue

Looks like the build pipeline has been broken, since #88 was merged. When a PR is merged to main, the check Build & Release fails.

How the pipeline works

The release happens in two separate actions, in the same workflow:

• rymndhng/release-on-push-action. This action will create a GitHub release every time there is a merge to master. The type of the release can be set using a label in the PR that was merged: minor, mayor or patch. A special label, norelease, will make this action a noop. Before #88 the default was minor, now it is norelease.

• svenstaro/upload-release-action. This action will attach a file (namely the built library) to the GitHub release created by the previous action

Issues with current pipeline.

1. If the label norelease (which is the default) is used, then the second action will fail because there is no release to attach the file to. Note that this is only cosmetic. Failing to attach the file to the release only causes a ❌ in the UI, nothing bad actually happens.
2. This only creates GitHub releases, it doesn't create NPM releases. This is mostly harmless because main consumers of this card will install it using HACS, not form NPM. But there are use cases where a NPM release is desired (for example, if a card extends this one, or users are composing their HomeAssitant frontend manually without HACS).
3. Similar to 2, the release pipeline doesn't increase the version in package.json nor maintains a CHANGELOG.md in the repo. Again, not a hard requirement, just a nice to have.

Potential solutions

Problem 1

For Problem 1, there are no way to skip a workflow step based on the output of another step (afaik). We could do it using separate workflows though:

• Main workflow that does yarn lint + yarn build + release-on-push.
• Secondary workflow runs only if the previous workflow created a GitHub release. This secondary workflow will do upload-release-action

Problem 2

Solutions for Problem 2 and Problem 3 are more complex. In my opinion, the perfect process will:

• Not require to run anything locally, everything happens on Github
• Update CHANGELOG.md
• Update package.json
• Publish to NPM
• Create a GitHub release (for HACS)
• Trigger via GitHub UI, not a PR.

Solving Problem 2 and 3 requires more investigations.

[scinos]

I'll prepare a fix for the Problem 1 with the solution proposed above, then we can discuss about Problem 2.