Oleks
bdc43bb1d6
ci/woodpecker/push/container Pipeline was successful
The deploy/fleet-overlay templates had drifted from what actually runs in anton-helm-workloads (verified live + against the emdash-kotkanagrilli reference). Canonical design co-locates everything in the `kotkan` namespace: - source.yaml: GitRepository flux-system -> kotkan, so the HelmRelease chart sourceRef resolves same-namespace (no cross-namespace ref). - secrets.yaml: deploy-key Secret -> kotkan, defined once in the staging overlay; dropped the duplicate definition from the production overlay (production references the shared key by name). - image-automation.yaml: IUA write-back sourceRef anton-workloads-image-automation/flux-system -> anton-helm-workloads/kotkan (the existing read source already has push access). - README.md / DEPLOYMENT.md: namespace + ownership docs corrected.
82 lines
2.6 KiB
YAML
82 lines
2.6 KiB
YAML
---
|
|
# Watch the Gitea OCI registry for the floating `production` tag. Every
|
|
# push to the production branch retags the new image as `production`,
|
|
# overwriting the previous binding (OCI tag→manifest is single-valued).
|
|
# The image's immutable `0.1.<N>` tag stays in the registry as audit.
|
|
apiVersion: image.toolkit.fluxcd.io/v1
|
|
kind: ImageRepository
|
|
metadata:
|
|
name: cms-plugins-production
|
|
namespace: kotkan
|
|
spec:
|
|
image: git.oleks.space/oleks/cms-plugins
|
|
interval: 1m
|
|
secretRef:
|
|
name: gitea-registry-creds
|
|
---
|
|
# Only the `production` floating tag is in scope. There's at most one
|
|
# match at a time, so alphabetical ordering is a no-op — the policy
|
|
# just resolves to that single tag's current digest.
|
|
apiVersion: image.toolkit.fluxcd.io/v1
|
|
kind: ImagePolicy
|
|
metadata:
|
|
name: cms-plugins-production
|
|
namespace: kotkan
|
|
spec:
|
|
interval: 1m
|
|
imageRepositoryRef:
|
|
name: cms-plugins-production
|
|
filterTags:
|
|
pattern: '^production$'
|
|
# Extract and reflect the resolved digest into helmrelease.yaml.
|
|
# This enables IUA to pin by digest, which makes helm upgrade detect
|
|
# changes when the floating tag is reassigned.
|
|
digestReflectionPolicy: Always
|
|
policy:
|
|
alphabetical:
|
|
order: asc
|
|
---
|
|
# IUA writes the resolved digest into helmrelease.yaml — pinning by
|
|
# digest is what makes `helm upgrade` see a change when the floating
|
|
# tag is reassigned (without digest, tag stays `production` literal and
|
|
# helm upgrade is a no-op).
|
|
#
|
|
# NOTE: `sourceRef` is the WRITE-back target — a GitRepository (with a
|
|
# write-capable deploy key) pointing at the workloads repo this manifest
|
|
# lives in. We reuse the same `anton-helm-workloads` GitRepository in
|
|
# `kotkan` that Flux already uses to READ these workloads; its deploy key
|
|
# has push access, so IUA commits the pinned digest straight back to
|
|
# `main`. (The emdash-kotkanagrilli reference instead uses a dedicated
|
|
# `oleks-fleet-image-automation` source because its workloads live in the
|
|
# fleet repo — same idea, different repo.)
|
|
apiVersion: image.toolkit.fluxcd.io/v1
|
|
kind: ImageUpdateAutomation
|
|
metadata:
|
|
name: cms-plugins-production
|
|
namespace: kotkan
|
|
spec:
|
|
interval: 1m
|
|
sourceRef:
|
|
kind: GitRepository
|
|
name: anton-helm-workloads
|
|
namespace: kotkan
|
|
git:
|
|
checkout:
|
|
ref:
|
|
branch: main
|
|
commit:
|
|
author:
|
|
email: flux-bot@oleks.space
|
|
name: flux-bot
|
|
messageTemplate: |
|
|
chore(cms-plugins-production): pin new digest
|
|
Files:
|
|
{{ range $filename, $_ := .Changed.FileChanges -}}
|
|
- {{ $filename }}
|
|
{{ end -}}
|
|
push:
|
|
branch: main
|
|
update:
|
|
path: ./cms-plugins-production
|
|
strategy: Setters
|