Publish chart on Dockerhub #525
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: lunny/helm-chart#525
Reference in New Issue
Block a user
No description provided.
Delete Branch "refs/pull/525/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As title.
blocked by #526
@ -92,2 +82,3 @@Gitea can be run with an external database and cache.This chart provides those dependencies, which can be enabled, or disabled via configuration.### HA DependenciesFor the "old" way you'd still need to run
helm repo update.OCI registries cannot be added as Helm repositories, afaik. Installing a chart from an OCI registry is a oneliner:
helm install gitea oci://registry-1.docker.io/gitea/helmwith an optional--version "<chart-version>".Ah interesting. TF didn't complain but I guess because it directly uses the
helm installapproach. Thanks!Uhm, @pat-s. I've played with the
helm pushcommands towards DockerHub. Looks like it wouldn't work how we intend to split Gitea images from Helm Chart. Please give me a few minutes to write a more in-depth experience with screenshots and what I understood so far.Why I rejected the current state
This is based on the official docs for how to push OCI artifacts to DockerHub and testing with my own account and a private repository.
What is a DockerHub repository
Looking at the docker/demo repository, you can have different artifact types. But every tag must be unique. If not, pushing another artifact type over an existing tag, the previously existing tag still exists but is only accessible through the digest. The tag is rewritten. I've tested this in my private repository
justusbunsi/helm.Having an image tag 0.1.0
After pushing a Helm Chart with version 0.1.0 into this repository
What happens when accessing the image via tag
What would work
Pushing a Helm Chart to DockerHub
When pushing a Helm Chart to DockerHub, the OCI address is
oci://registry-1.docker.io/<username>. Trying to use an address likeoci://registry-1.docker.io/<username>/<repository>results in an error message likeError: push access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed.There are other OCI-compatible registries like Harbor where you could do that. Even with more subpaths. But DockerHub seem to not support that.
The helm command automatically determines what artifact it is processing by reading the Chart.yaml in the tgz file. In our case, the artifact name would be
gitea. The version would be9.6.0and newer versions when starting this.helm pushwill combine the given OCI address and the artifact name and would push an artifact with tag9.6.0tooci://registry-1.docker.io/gitea/gitea, leading to a mixed repository like thedocker/demois. This may be no issue right now due to Gitea not bumping the official major version and the Helm Chart already being on major 9. But at some point this can result in issues like above in the first section.EDIT: When using
helm pull oci://registry-1.docker.io/<username>/<repository>without an explicit version via--versionflag, Helm extracts all tags in this repository, sorts them and compares them according to semver. Tags like1.20-nightlywould be1.20for Helm. This can create lots of headache.The gitea/helm repository
Having experienced the above, I would say that the
gitea/helmrepository won't be used as long as we don't name our Helm Charthelmand publish versions for that. There is no way to overrule the Chart name during helm package command, like for appVersion or version.A possible solution?
When looking at Bitnami Helm Charts, their
helm installinstructions refer tooci://registry-1.docker.io/bitnamicharts/<chart>. It seems Bitnami uses abitnamiuser for providing Docker images and abitnamichartsuser for providing Helm Charts. That's why they can name their repositories identical for both artifacts, without colliding tags.Right now, I am really unsure what to do. The most clean solution would be using different DockerHub accounts. But that would double payments, right? Am I missing anything that would allow us to make our current approach work?
Oh wow, thanks for the deep dive! Which was truly needed given the points you discovered (and I was not aware about and learned today). Thanks a lot!
I agree that under these circumstances we should not release it in it's current form as this would result in a mixed
gitea/gitearepository.And yes, renaming the chart is also not an option imo only for this feature.
You don't need to pay necessarily for a "working" dockerhub account - and if this one is only used for the charts, I don't think that going with the free version would be an issue.
So if @techknowlogick would agree, I think a second account for publishing the charts would be a possible solution.
It could be named
giteachartsor similar and then the final URL would beoci://registry-1.docker.io/giteacharts/gitea.I have created the new org
giteachartsplease try again. secrets names has been changed.@justusbunsi After lunny created https://hub.docker.com/r/giteacharts/gitea, I've adjusted the secrets and README. I think this approach should be "safe" now?
@ -56,3 +54,3 @@# push to dockerhubecho ${{ secrets.DOCKER_CHARTS_PASSWORD }} | helm registry login -u ${{ secrets.DOCKER_CHARTS_USERNAME }} registry-1.docker.io --password-stdinhelm push gitea/gitea-${GITHUB_REF#refs/tags/v}.tgz oci://registry-1.docker.io/giteachartshelm push gitea-${GITHUB_REF#refs/tags/v}.tgz oci://registry-1.docker.io/giteachartsThis should push the chart to
oci://registry-1.docker.io/giteacharts. See section "Pushing a Helm Chart to DockerHub" in my deep dive.Well spotted 👍
Should be good to go now. You mentioned that DockerHub charts will are available "since v9.6.0": Do we wait with merging the PR until we release that version?