Automate all the things #2
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
We need a pipeline for Drone to automatically build and push new releases of the chart (Is there a build step? I don't know enough about Helm).
Should we only publish when tagging a release in this repo? Should the version number follow the release numbers for the frontend and api?
In order to publish the chart as a package in Gitea.
helm package .It will produce a tarball with the chart
You can use either curl to do that or helm cm-push plugin. This is described in the contributing section.
I would suggest to use curl, because it is present in most CIs and you can avoid installation of the cm-push plugin for Helm.
You can just specify
./*.tgzas an archive name.Chart version is specified in the Chart.yaml file, hence, I would suggest triggering pipeline on change in Chart.yaml only. Other files not important as a trigger source.
I am not sure, that got your point :) Anyway, there is a line in the Chart.yaml that stands for application version. I have build the chart in the way, when this particular value is used as a tag for both frontend and api images. So that, you can just set appVersion to newer version in order to update both applications.
Nevertheless, end user is able to override the application version during the deployment (without chart rebuild), just setting up tags values. If tag is not an empty string, appVersion from Chart.yaml is ignored. There is a place where this behavior is implemented: API, Frontend.
P.S. @konrad feel free to ping me with mentioning my login in the message :) I have spotted this issue occasionally. Or just assign it on me.
Drone runs with Docker images only - it has nothing by default and everything we need as long as there's a docker image for it. Looks like there's a docker image with cm-push we could use so it does not really matter which route we go.
What happens if a chart with the same version is published again? Does it make sense to template the version number in Chart.yml and build a pipeline around it so that it would only publish when tagging the repo? (replacing the version number in the chart file with the tag name)
There might be occasions where the last api and frontend release have different version numbers (as is the case right now). Probably better to specify them individually, even if the numbers will be the same most of the time.
I do however aim to have at least the same minor versions for both the frontend and the api. For example, 0.20.0 were released for both at the same time. The question is if we should follow that convention when releasing new chart versions? (For the version numbers of the chart)
Okay :) this is a minor technical detail
It will be overriden in the repository. I see that you want to use tags to version the chart, but I am not sure that it is a best way to go, while it is possible anyway. I always prefer to set version in Chart by hands and update it in commits.
Let's image the following case.
Chart version is to be increased in case of any change to its content, even a single line. Saying change, I mean value or template change. If we fix typos or whitespaces - we can use the same version.
Version name of chart should not be the same as appVersion, but rules that if try to follow are:
P.S. @konrad Sorry for the long reploy timeout, had a hard week
Thanks for the explanations! Sorry for the late reply, there's been too much going on last week outside Vikunja.
Okay, that makes sense. I think my reasoning to only set the version number and publish based on a tag name was to accidentally prevent overriding an old version when changing something without increasing the version number in the same commit. As long as increasing the version number is a manual task, that will happen at some point. Better make it explicit via tags.
But as long as the chart will be published on each push to the main branch, this would override the last release even if nothing changed?
Hi @konrad !
Okay, that will work.
Not the last one, but one that matches version field in the Chart.yaml, but yes, it will override.
@konrad, I have debugged the chart and pushed it to packages (0.1.2)! I have Vikunja launched on my k3s cluster at https://vikunja.vlasov.pro. Let me know if You need credentials and want to test it.
It uses unstable tag for both api and frontend for now, and we will migrate to stable version after new Dockerfiles will propagate to stable version.
If it is possible, we can make a call and I will show all technical points You want to know about.
Looks good! Two things I wonder:
I'd love to :) I'll ping you via mail to figure out the details.
Right now - no, but I can implement that as well.
Chart passes complete config.yaml to the API, so any key that are present in you configuration can be passed to the API.
Thanks for the meeting!
Some notes.
To publish the chart properly on Artifacthub, we need to claim ownership of the Vikunja org first so that it shows up as official. This needs a metadata file and a way to serve that from our Helm repo (Gitea)
I'll try to add a drone pipeline to publish automatically on git tag.
@konrad
Thanks for the call resume you have posted above!
I have a question regarding hosting on one domain. It is obvious that traffic will be splited basic on URI path. If I want to host API at /qwer1234 - what config option I have to set so that API will be aware of such path?
There's no option to make the api aware of that path. I think you'd need to work with the
X-Forwarded-Pathheader, but I never tested that.The bigger problem is hosting the frontend on a sub path as the bundle assumes it is hosted on a domain. There's a docs article on how to build is with a subpath in mind: https://vikunja.io/docs/running-vikunja-in-a-subdirectory/ but that's static.
TBH I think it would be fine if we just wouldn't support hosting on a sub path and start figuring something out when people ask for it.
That sound great! It was always easier to enable CORS and create a subdomain then play with different paths on the same domain.
PR for automation is up: #3