Skip to content

feat: publish config/ as an OCI manifests artifact for Flux#56

Draft
TeddyAndrieux wants to merge 1 commit into
mainfrom
feature/add-flux-oci-build
Draft

feat: publish config/ as an OCI manifests artifact for Flux#56
TeddyAndrieux wants to merge 1 commit into
mainfrom
feature/add-flux-oci-build

Conversation

@TeddyAndrieux

Copy link
Copy Markdown
Contributor

What

Publish the deployment manifests (the config/ tree) as an OCI artifact alongside the
operator image, so Flux can deploy crl-operator directly from the registry (no checkout):

  • controller image: ghcr.io/scality/crl-operator:<version>
  • manifests artifact: ghcr.io/scality/crl-operator-manifests:<version>

Changes

  • .github/workflows/build.yaml: split into a tags job (computes the version + optional
    latest) and two jobs that consume it — operator-image (controller image, unchanged
    build-push-action) and manifests-image (make push-manifests). Both run on every build,
    not only on release.
  • Makefile: a REGISTRY variable (shared by IMG and MANIFESTS_IMG), a self-contained
    flux tool target, and a push-manifests target, grouped in a dedicated section separate from
    the operator-sdk scaffolding.
  • README.md: documents the artifact with a Flux deployment example.

Notes

The manifests artifact always pins the controller image at the specific version it was built for
— even its latest tag re-tags the same artifact — so the bundle never drifts from the image
across releases.

Publish the deployment manifests (this repo's config/ tree) as an OCI artifact
Flux can consume directly (OCIRepository + Kustomization), alongside the
operator image, so GitOps deployments can pull a versioned bundle.

build.yaml is split into a `tags` job that computes the version (+ optional
`latest`) and two jobs that consume it: `operator-image` builds and pushes the
controller image, `manifests-image` runs `make push-manifests`. Both run on
every build, not only on release.

The manifests artifact always pins the controller image at the specific
version it was built for - even its `latest` tag re-tags the same artifact -
so the bundle never drifts from the image across releases.

The Makefile gains a `REGISTRY` variable (so `IMG` and `MANIFESTS_IMG` share the
ghcr namespace), a self-contained `flux` tool target, and a `push-manifests`
target, grouped in a dedicated section separate from the operator-sdk
scaffolding. The README documents the artifact with a Flux deployment example.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant