search

argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
17.23k stars 5.23k forks source link

Opt out of caching prerelease helm artifacts #14728

Open jcogilvie opened 1 year ago

jcogilvie commented 1 year ago

Summary

I propose that argo's repo server should opt out of caching artifacts which helm deems to be prerelease (or provide a mechanism thereto).

According to helm's semver library a version like 2.1.0 is a release artifact but 2.1.0-branch-name is prerelease, in that it is semver less-than 2.1.0.

Motivation

I maintain the helm charts inside my company. When I make a change in my helm chart lib, this creates or updates a prerelease artifact named after the branch it was built from, such as 2.1.0-branch-name. This is a static name for a moving prerelease artifact, which on merge gets promoted to a stable version like 2.1.0.

In order to validate the helm chart, I will deploy an application which is built atop the chart at the prerelease version, using the app's own CI pipeline. But, today, I only get one try at this, because the artifact is cached. If it changes, I have to hard refresh from the CLI or spawn a new branch to get a new artifact name.

Proposal

How do you think this should be implemented?

A flag in the repo server most likely. When downloading an artifact, and moving to cache it, detect whether it meets criteria for a semver prerelease. If so, skip the cache.

jessebye commented 3 months ago

What if you added a build number to your prerelease artifact versions? I.e. 2.1.0-branch-name.123 or 2.1.0-branch.name+123? Curious if that'd resolve the problem.

jcogilvie commented 3 months ago

Maybe if there's a way to specify "always the latest one" somehow in a version range.

Otherwise it would mean I have to alter the consuming chart every time the dep changes, which would defeat the purpose of having branch-tracking prerelease artifacts.

jessebye commented 3 months ago

@jcogilvie This works for me in the Argo app:

targetRevision: ">= 0.0.0-my-prerelease-branch.0 < 0.0.0-my-prerelease-branch.z"

I use z there since it has higher ASCII numerical value than any number. Weird but that's how semver comparison works (I think).

But you mention a "consuming chart" - I don't think this will work if your prerelease chart is consumed by another chart first, then that chart is templated by Argo. At least if your consuming chart has a Chart.lock, that will always pin the dependent chart to a specific version because it uses a digest.