Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix release pipeline #159

Open
scinos opened this issue Nov 10, 2024 · 1 comment
Open

Fix release pipeline #159

scinos opened this issue Nov 10, 2024 · 1 comment

Comments

@scinos
Copy link
Collaborator

scinos commented Nov 10, 2024

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 Disable default release-on-push action #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
Copy link
Collaborator Author

scinos commented Nov 10, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant