ArgoCD: ImageTagUpdate accepts Helm Paths to update via variables#1787
ArgoCD: ImageTagUpdate accepts Helm Paths to update via variables#1787
Conversation
|
|
||
| public static string IndexedPackagePurpose(string packageReferenceName) => $"Octopus.Action.Package[{packageReferenceName}].Purpose"; | ||
|
|
||
| public static string HelmValueYamlPath(string packageReferenceName) => $"Octopus.Action.Package[{packageReferenceName}].HelmValueYamlPath"; |
There was a problem hiding this comment.
Based on what I used in my PRs
| public static string HelmValueYamlPath(string packageReferenceName) => $"Octopus.Action.Package[{packageReferenceName}].HelmValueYamlPath"; | |
| public static string HelmValueYamlPath(string packageReferenceName) => $"Octopus.Action.Package[{packageReferenceName}].HelmReplacementPath"; |
Alternatively I can change it on my PRs to match what you have
There was a problem hiding this comment.
I went with HelmReplacementPath 👍
|
|
||
| public static readonly string PurgeOutput = "Octopus.Action.ArgoCD.PurgeOutputFolder"; | ||
|
|
||
| public static readonly string UseHelmValueYamlPathFromStep = "Octopus.Action.ArgoCD.UseHelmValueYamlPathFromStep"; |
There was a problem hiding this comment.
Seems strange that is this under the git class, but it all the other ArgoCD stuff is under there so 🤷
There was a problem hiding this comment.
yeah - thankfully its now gone :)
| return new UpdateArgoCDAppDeploymentConfig(commitParameters, packageReferences); | ||
| var packageHelmReference = deployment.Variables.GetContainerPackages().Select(p => new ContainerImageReferenceAndHelmReference(ContainerImageReference.FromReferenceString(p.PackageName), | ||
| p.HelmReference)).ToList(); | ||
| var useHelmValueYamlPathFromStep = deployment.Variables.GetFlag(SpecialVariables.Git.UseHelmValueYamlPathFromStep, false); |
There was a problem hiding this comment.
Is the reason for using this new variable over the feature toggle due to the fact turning off the feature toggle won't exactly be backwards compatible e.g. we release this, people convert to using the step method, we then turn the feature toggle off and all of a sudden their deployments stop working because we are expecting an annotation containing the replacement path
There was a problem hiding this comment.
hmmm.
Wondering about the featureToggle.
If we turn it on - and people set variables - then they turn it off.
The variables will remain in the deployment I suspect (?) - but Calamari shouldn't really use them.
With that all in mind - we probably should factor in the feature toggle here too.
tleed5
left a comment
tleed5
left a comment
There was a problem hiding this comment.
Looks good to me, just one question around the logging
| var imagesWithNoHelmReference = deploymentConfig.ImageReferences.Where(c => c.HelmReference is null).ToList(); | ||
| if (imagesWithNoHelmReference.Any()) | ||
| { | ||
| foreach (var image in imagesWithNoHelmReference) | ||
| { | ||
| log.Info($"{image.ContainerReference.ToString()} will not be updated, as no helm yaml path has been specified for it in the step configuration"); | ||
| } | ||
| } |
There was a problem hiding this comment.
Wouldn't this log everytime someone deploys even if they are updating non-helm sources?
2 participants
This change can be included without changes to server, as the changes will be ignored until appropriate changes exist in server.
When dealing with Helm(and ref) sources, the Argo Image Tag Update step is responsible for inserting image-tags (aka versions) into the value's files being referenced.
The User is required to inform Octopus which values represent an image version (it is not obvious as per normal K8s which have schemas for their yaml files).
Prior to this change, the user would need to insert the helm-values to update in a source-scoped annotation on the application - this was complex!
To simplify the process - we now allow users to specify an extra field on each container/package referenced by the step, this field is to contain the helm-value containing the tag/version of the associated container/package.
The helm-value specified could contain one of the following content-types:
If the specified helm-value contains additional information - the step will ensure the available data correlates with the package in the step prior to updating just the tag information in the value string.