helm: release: Publish our helm charts to the OCI registries #11264
Conversation
.github/workflows/release.yaml
Outdated
| release_version=$(./tools/packaging/release/release.sh release-version) | ||
| helm push kata-deploy-${release_version}.tgz oci://quay.io/kata-containers/kata-deploy-charts | ||
| helm push kata-deploy-${release-version}.tgz oci://docker.io/katadocker/kata-deploy-charts | ||
| helm push kata-deploy-${release-version}.tgz oci://ghcr.io/kata-containers/kata-deploy-charts |
There was a problem hiding this comment.
Why are we pushing to three different repos? Which should we use for the official release documentation?
There was a problem hiding this comment.
That's a very good question.
- dockerhub: was the first one used
- quay.io: I've created that one as dockerhub had the rate limit
- ghcr.io Came up later, and I think we should use this one, but our kata-deploy releases go to both quay.io and docker.io
I'd stick to ghcr.io if possible, for the helm charts.
There was a problem hiding this comment.
Yeah, I think we are currently mostly using quay.io for release (and nightly) artifacts and ghcr.io for CI artifacts. It would be good to standardise on a single place and I guess that ghcr.io makes the most sense, but maybe publishing to all three is the pragmatic step for now until we have a better strategy? However if we are going to pick one then I guess ghcr is the most likely strategic direction I see?
There was a problem hiding this comment.
For ghcr.io we do not have to save additional secrets. But having three directories in the documentation will confuse people, so I would say stick to ghcr.io in the public documentation?
There was a problem hiding this comment.
Yes, please, stick to ghcr.io in the public documentatiom.
.github/workflows/release.yaml
Outdated
| helm push kata-deploy-${release_version}.tgz oci://quay.io/kata-containers/kata-deploy-charts | ||
| helm push kata-deploy-${release-version}.tgz oci://docker.io/katadocker/kata-deploy-charts | ||
| helm push kata-deploy-${release-version}.tgz oci://ghcr.io/kata-containers/kata-deploy-charts |
There was a problem hiding this comment.
I think action-lint wants this change:
| helm push kata-deploy-${release_version}.tgz oci://quay.io/kata-containers/kata-deploy-charts | |
| helm push kata-deploy-${release-version}.tgz oci://docker.io/katadocker/kata-deploy-charts | |
| helm push kata-deploy-${release-version}.tgz oci://ghcr.io/kata-containers/kata-deploy-charts | |
| helm push "kata-deploy-${release_version}.tgz" oci://quay.io/kata-containers/kata-deploy-charts | |
| helm push "kata-deploy-${release-version}.tgz" oci://docker.io/katadocker/kata-deploy-charts | |
| helm push "kata-deploy-${release-version}.tgz" oci://ghcr.io/kata-containers/kata-deploy-charts |
Is test it live not our usual approach? 🙃 |
b2f16b1 to
3519e74
Compare
Let's take advantage that helm take and OCI registry as the charts, and upload our charts to the OCI registries we've been using so far. Signed-off-by: Fabiano Fidêncio <fidencio@northflank.com>
3519e74 to
71e8c1b
Compare
|
This is a release workflow change, so we have no way of testing it (eek), and the gatekeeper run is green, so we'll need to use admin rights to get this merged. |
Let's take advantage that helm take and OCI registry as the charts, and upload our charts to the OCI registries we've been using so far.
NOTE: I'd like to ask someone from the @kata-containers/architecture-committee on what's the best way to try this out before the release, before it gets merged.. :-)