-
Notifications
You must be signed in to change notification settings - Fork 1.5k
feat(release): push helm charts to OCI registry and build helm index #11626
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
base: master
Are you sure you want to change the base?
Conversation
This allows Helm charts to be published to container registries with OCI support. Currently only pushing to quay.io at quay.io/calico/charts and charts can be pulled using: ```sh helm pull oci://quay.io/calico/charts/tigera-operator --version VERSION ``` wrt: projectcalico#11376
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds support for publishing Calico helm charts to an OCI registry (quay.io/calico/charts) and implements incremental helm index updates during releases to preserve accurate creation dates.
Key changes:
- Helm charts are now pushed to OCI registries via
helm pushin addition to GitHub releases - Helm index is now incrementally updated by merging with the existing index instead of full rebuilds
- New CLI flags and configuration options for helm registry management and S3 bucket access
Reviewed changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| release/pkg/tasks/hashrelease.go | Updated comments to clarify versionless chart copy behavior |
| release/pkg/postrelease/helm_test.go | Added OCI registry tests to validate charts can be pulled from new registries |
| release/pkg/manager/calico/options.go | Added options for AWS profile, S3 bucket, chart publishing, and helm registries |
| release/pkg/manager/calico/manager.go | Implemented helm chart publishing to OCI registries, incremental index building with merge, and S3 upload logic |
| release/internal/utils/utils.go | Added constants for TigeraOperatorChart name and CalicoHelmRepoURL |
| release/internal/registry/registry.go | Defined default helm registries list (quay.io/calico/charts) |
| release/internal/hashreleaseserver/server.go | Fixed typo in comment |
| release/cmd/release.go | Wired new CLI flags for chart publishing and AWS/S3 configuration |
| release/cmd/hashrelease.go | Added helm registry and chart publishing flags to hashrelease commands |
| release/cmd/flags.go | Defined new CLI flags for helm registries, AWS profile, S3 bucket, and chart publishing |
| release/Makefile | Added dependency on helm binary for hashrelease-publish target |
| Makefile | Made chart destination directory configurable via CHART_DESTINATION variable |
| .semaphore/release/release.yml | Added helm registry login to quay.io in CI pipeline |
| .semaphore/release/hashrelease.yml | Added helm registry login to quay.io in CI pipeline |
- fix typo - add check for helm registry and s3 bucket when publishing charts - use static helm registry in release notes template - add `oci://` prefix to registry when pushing charts - fix postrelease tests for helm charts
Description
This add updates to Calico's helm charts specifically the following:
pushing charts to an OCI registry: the tigera-operator chart now gets pushed to
quay.io/calico/chartsfor use.# template: helm <applicable_chart_cmd> oci://quay.io/calico/charts/tigera-operator <flags_as_needed> helm pull oci://quay.io/calico/charts/tigera-operator --version VERSIONupdate helm index during release. This should replace the current approach of rebuilding the entire helm index which leads to incorrect create date.
Related issues/PRs
created#6747Todos
Release Note
Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one
docs-*label.docs-pr-required: This change requires a change to the documentation that has not been completed yet.docs-completed: This change has all necessary documentation completed.docs-not-required: This change has no user-facing impact and requires no docs.Every PR needs one
release-note-*label.release-note-required: This PR has user-facing changes. Most PRs should have this label.release-note-not-required: This PR has no user-facing changes.Other optional labels:
cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.