docs(argo-cd): publish HelmReplacementPath OCL property + clarify valueFiles handling for Update Image Tags step#3141
Open
vlussenburg wants to merge 4 commits into
Conversation
…behaviour Two related gaps in the Update Argo CD Application Image Tags doc that trip up Config-as-Code users: 1. **OCL property name is undocumented.** The page describes the "Helm image tag path" UI field but never names the OCL/HCL key it serialises to. Users editing deployment_process.ocl directly have to read Calamari source (PackageVariables.HelmReplacementPath) to find that the field is `HelmReplacementPath` on the package reference and the resolved variable is `Octopus.Action.Package[<ref>].HelmReplacementPath`. Octopus silently strips unrecognised property names from saved OCL, so guessing (`HelmImageTagPath`, `Octopus.Action.ArgoCD.HelmImageTagPath`, etc.) yields no error — the step just stays a no-op at runtime, which is hard to diagnose. Added an OCL-focused info block with a complete package block example. 2. **"Helm charts" section understates what the step writes to.** The page says "matching image tags in the values.yaml are replaced", which reads as if only the chart's default values.yaml is touched. In practice, when `HelmReplacementPath` is set, the step ALSO writes to every file listed in the Application's spec.source.helm.valueFiles (verified against Calamari/source/Calamari/ArgoCD/Conventions/UpdateImageTag/HelmUpdater.cs `ProcessHelmSourceUsingStepVariables`). This is the behaviour any real per-env Helm-on-Argo setup depends on. Conversely, inline `spec.source.helm.valuesObject` is NOT written — also worth calling out so people don't go hunting. Rewrote the section to spell out both paths (step-configured vs annotation-driven) and the valuesObject limitation explicitly.
|
|
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
3 participants
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.
Two gaps in the Update Argo CD Application Image Tags doc that bit me on a CaC project.
The OCL property name for "Helm image tag path" isn't documented. The UI field is described, but if you're editing
deployment_process.oclby hand you need to know it serialises toHelmReplacementPathon the package reference (resolved deployment-time asOctopus.Action.Package[<ref>].HelmReplacementPath). I found this by readingPackageVariables.HelmReplacementPathin Calamari. The OCL save silently strips unknown property names, so guessingHelmImageTagPath(or similar) gives no error — the step just runs as a no-op forever. Added an OCL example.The "For Helm charts" section reads as if only the chart's default
values.yamlis touched. In practice, whenHelmReplacementPathis set, the step also writes to every file listed in the Application'sspec.source.helm.valueFiles(seeHelmUpdater.ProcessHelmSourceUsingStepVariables). Inlinespec.source.helm.valuesObjectis not written — worth calling out, since users with valuesObject-based Applications will otherwise chase missing tag bumps. Rewrote the bullets to spell out both code paths and the valuesObject limitation.Found while debugging an Octopus + Argo CD setup that ran "Success" but reported
Nothing to update for Applicationfor days — one guessed OCL property, one valuesObject Application.