Versioned Git Tag Tracking - similar to ArgoCD Image Updater

[diranged]

Summary

When using private Github repositories to manage all of your Application objects, you run into the question of how you are going to manage updating ArgoCD to point to the right version of the repository. There is currently Tag, Branch, and Commit pinning, but they are limited in their function set.

I propose updating the Tag tracking to be able to follow all new tags being created in the repository, and to be able to select the tags using patterns that have been developed in the ArgoCD Image Updater repository (see https://github.com/argoproj-labs/argocd-image-updater/blob/master/docs/configuration/images.md#update-strategies, https://github.com/argoproj-labs/argocd-image-updater/blob/master/docs/configuration/images.md#filtering-tags and https://github.com/argoproj-labs/argocd-image-updater/blob/master/docs/configuration/images.md#ignoring-certain-tags).

Motivation

Mutating tags is something that we consider "bad" internally. That is - we don't want to have a production tag and simply move that around because it makes it very hard to track how and why something happened. There is no real history associated with where a tag was yesterday vs today for example. It also makes leveraging the Github "Release" feature pretty much useless.

We have always used Git tags to manage our deploys.. the tagging strategies vary by team, but being able to quickly see that a new deploy was released because there is a new tag in the repo, and then being able to diff that tag to the previous release is pretty critical.

Proposal

The ArgoCD Image Updater project has done much of the leg work from a "logic" perspective I think, and ideally that logic could be packaged up into a shared library or something between these projects. In addition to targetRevision, I'd like to see a new parameter added in named targetTracking and make that an object. For example:

spec:
  destination:
    namespace: myapp
    server: https://kubernetes.default.svc
  project: default
  source:
    helm:
      valueFiles:
      - values.yaml
    path: projects
    repoURL: git@github.com:OurOrg/MyApp.git
    targetTracking:
      updateStrategy: [ semver, latest, name ]
      allowTags: [ <any>, <regex pattern>, ... ]
      ignoreTags: [ <glob pattern>, <regex pattern>, ... ]

In-Practice Examples

Follow Semver-packaging but only in the 1.2.x branch. Include any additional string added to the end of a semvar: 1.2.0, 1.2.10, 1.2.30.alpha.1:

targetTracking:
  updateStrategy: semver
  allowTags: [ '1\.2\.[0-9]+.* ']

Follow a simple numeric pattern: 0001, 0002, 0003, 0020, etc:

targetTracking:
  updateStrategy: latest
  allowTags: [ '[0-9]{4}' ]

[pnowy]

I have to say that would be great to have this feature.

We have the similar problems that branching strategy is super complex for human tracking when there is a lot merges between branches and additionally when you store a couple of configs in one repo that you have to merge all or nothing.

Also with quite popular app of apps patter if you want use parent app pinned to specified tag on the CI you have to first sync that specific app in parent app (to start pointing argo application into different pinned commit) and in second step you are able to sync real manifest. With this feature and possibility to add that kind of tracking strategy it will be much easier to manage in single repo multiple config (per tag prefix for example) and just sync in one step (then argo app-of-apps define only correct strategies).

Yes - above would extend a lot of possibilities with complex distributed systems.

[jherediacmp]

i would love to see that working.

As in our workflows, we use as well git tag pushes ,to trigger image build and deploys in kube. Having this available , would simplify my life a lot.

[edude03]

Would love to see this as well

[erkerb4]

We have the similar problems that branching strategy is super complex for human tracking when there is a lot merges between branches and additionally when you store a couple of configs in one repo that you have to merge all or nothing.

I found this enhancement to share this same point.. I am a bit late to the party, but I also support this enhancement idea.

[Mais316]

Could we please consider this enhancement request as we are sort of blocked when we have to create a new app tag then its not auto picked.

[diranged]

While I still want this to be built - we did work around this internally. Every time we create a release (via github), we have a github action that automatically moves the production tag to that release. So we can point Argo at production while still using github releases. It's stupid simple... just annoying though that we can't have Argo understand the actual release version/tag-name.

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: Update the Production Tag
      run: git tag production --force && git push origin production --force

[jheck88]

Bumping this.

This seems like a great feature, considering I want to ensure that my pipelines pass before argo updates. I could add a patch and manual sync but that seems no better then a standard helm deploy.

Willing to support this.

[rafilkmp3]

This would make it possible to use argocd with TDB https://trunkbaseddevelopment.com/ which is in my humble opinion, the holy grail of gitops

[Cayan]

This would be a great feature indeed

[RamazanKara]

Would also really love this

[ThomasSteinbach]

Oh nooo. It got so far implementing ArgoCD in our team, just to realize now that we can't apply staging deployments with SemVer tags.
How does someone survive without being able to describe deployment versions without SemVer? This proposal needs to be implemented - now ;)

Currently we have to re-tag releases for staging deployments. The Git documentation itself says to re-tagging:

The insane thing. You really want to call the new version "X" too, even though others have already seen the old one. So just use git tag -f again, as if you hadn’t already published the old one.

[crenshaw-dev]

I think this would be a really great feature, and I'd definitely try to get time to review a PR! My guess is the author could borrow code from our Helm semver support, but I'm not super familiar with that code.

[yo-ga]

In our team, we work with the trunk based flow. This enhancement feature would be great for us.
If this issue is become Help wanted state, some contributors may try to implement this.

[thepabloaguilar]

I'd love to work on this issue! My suggestion is to always use semver like Helm tracking does, it allows the two examples to be done! Of course the second one would need a little change to be compatible with semver.

I'm gonna try to submit a PR this week!

[mtrin]

this would be a great addition! upvoted

[migueleliasweb]

Any news about this feature? This would be ground breaking for various usecases!

I reckon the first release could be to only enable wildcards in the targetRevision, like v1.0.2-* and it could match against v1.0.2-build-1234 for example. This would already be super helpful!