feat(helm): publish a chart alongside the image - #179
Merged
Conversation
The backend is deployed from a generic `micronaut` chart that lives in the cluster repository and is shared with otis, so nothing here describes how this service runs. Every deployment therefore waits on someone editing an image tag by hand in that repository -- which is how dev ended up on 2.3.0 while prod ran 2.4.1. A chart of our own, versioned from the same release as the image, removes that step: image.tag is left empty and falls back to .Chart.AppVersion, so pinning the chart pins the image and an environment that tracks the newest chart release tracks the image with it. The chart is a fork of helm/micronaut rather than a rewrite -- the template helpers keep their `micronaut.*` names and the files are otherwise unchanged, so a later fix over there carries across with `diff -r`. Only what identifies this application is different: image repository, the 8080 the Micronaut server binds, and the Prometheus endpoint it always exposes. Packaged and pushed to the same Harbor project as the image, under charts/, chained into the release run for the same reason the docker job is: a GITHUB_TOKEN tag starts no `on: push: tags` workflow.
Contributor
Test results 42 files 42 suites 4s ⏱️ Results for commit ee2adc2. |
TheMeinerLP
added a commit
to OneLiteFeatherNET/Kubernetes-FLUX
that referenced
this pull request
Aug 24, 2026
Both environments were rendered from the generic helm/micronaut chart in this repository and paired with an image tag edited by hand in each HelmRelease. Nothing tied the two together, so they drifted: dev sat on 2.3.0 while prod ran 2.4.1, because the bump in acb2a0b touched prod only. The backend now publishes a chart alongside its image, versioned from the same release (OneLiteFeatherNET/Vulpes-Backend#179). image.tag is left empty and falls back to .Chart.AppVersion, so the source pin is the only version there is. Prod stays on an exact pin and is moved deliberately; dev takes an open range and follows the newest release on its own -- the same split stelaris-ui.yaml uses, and the reason two OCIRepositories point at one URL. Rendered old against new for both environments: nothing changes but the helm.sh/chart label and the config checksum that includes it, so prod sees a single rolling restart. Resource names and the immutable Deployment selector are held in place with nameOverride/fullnameOverride, since .Chart.Name reaches app.kubernetes.io/name and renaming it would need the Deployment deleted rather than upgraded. Pinned to 2.6.0, the first release that will carry a chart -- 2.5.0 was cut before the chart existed. Prod therefore moves from 2.4.1 straight to 2.6.0, and dev picks up both releases it missed. otis keeps using helm/micronaut, so that chart stays. Not mergeable until #179 is in and that release has run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The backend is deployed from a generic
micronautchart that lives in the cluster repository and is shared with otis, so nothing in this repository describes how this service runs. Every deployment therefore waits on someone editing an image tag by hand over there — which is how dev ended up on 2.3.0 while prod ran 2.4.1: the bump inacb2a0btouched prod only.A chart of our own, versioned from the same release as the image, removes that step.
image.tagis left empty and falls back to.Chart.AppVersion, so pinning the chart pins the image — and an environment that tracks the newest chart release tracks the image with it.What's here
charts/vulpes-backend/— a fork ofhelm/micronaut, not a rewrite. The template helpers keep theirmicronaut.*names and the files are otherwise unchanged, so a later fix over there carries across withdiff -r. Only what identifies this application differs: image repository, the 8080 the Micronaut server binds, and the Prometheus endpoint it exposes in every environment.release-please-config.json—Chart.yamladded toextra-files, so the chart version and the app version move together with the release. Both markers sit at 2.5.0 to match.release-please-manifest.json..github/workflows/release-please.yml— ahelmjob that packages and pushes tooci://<harbor>/onelitefeather/charts. Chained into the release run for the same reason the docker job is: release-please tags withGITHUB_TOKEN, and such a tag starts noon: push: tagsworkflow. Both versions are passed from the release output rather than read fromChart.yaml, so the chart cannot be packaged pointing at an image tag nobody built.Verification
Rendered the current cluster manifests against the new chart for both environments. Nothing changes but the
helm.sh/chartlabel and the config checksum that includes it — no resource name, no selector. Resource names are held in place from the cluster repository withnameOverride/fullnameOverride, because.Chart.Namereachesapp.kubernetes.io/name, which is in the Deployment's immutable selector and would need the Deployment deleted rather than upgraded.helm lintpasses.Notes
HARBOR_REGISTRY/HARBOR_USERNAME/HARBOR_PASSWORD) are organisation secrets here — the same onesstelarisuses for the identical job. The first release run is what confirms this repository is in scope for them.feat, so the first release carrying a chart will be 2.6.0. The matching cluster-repository change pins against that version.