Closed MindTooth closed 10 months ago
how do this work compared to how it is today? a new release is made if we push a new version tag. I guess mostly with how change log is generated and auto tagging?
You know what, I forgot about the existing one. 🤣
semantic-release will auto tag based on conventional commits and automatically provide a changelog in the release. I can't seem to find that gh-release provides this?
It is a possibility to integrate git-cliff to create a changelog from which can be included in the release using the action above.
Example:
With some tweaks to make it more pretty. A bit noicy with all pre-commit changes. Which I guess is also a reason to tag more often I guess. Using e.g. semantic release. 🤷🏻♂️
Anyhow, we need to create the pipeline to build the UI with each release. As it's now just a pre-bundled dist folder which does not get updated with NPM package upgrades. I'll see more into fixing this.
I've started the job on looking into how we can build the assets. Ended up in a rapid hole. 😅
Already located some stuff I want to change in preparation for changes related to this.
To build the assets, is there any more then what is done in build-ui
action needed?
edit: I was also considering, we may want to test install the produced wheel in the release workflow
Simplistic terms, no.
However, current setup is made way back. I’ve been looking into trying to improve it. Also I noticed that e.g. postcss-url hasn’t been updated for ages. I’m trying to clean stuff up.
Currently dist/
isn’t safe to delete. Been looking into using pnpm instead which is a ton faster. Using ViteJS, or maybe more of esbuild. Looking at something.
See if we can automate release of new versions.
Try something like https://github.com/nrkno/github-workflow-semantic-release which uses semantic-release.