github.com/argoproj/argo-cd/v3@v3.2.1/docs/user-guide/tracking_strategies.md (about)

     1  # Tracking and Deployment Strategies
     2  
     3  An Argo CD application spec provides several different ways of tracking Kubernetes resource manifests.
     4  
     5  In all tracking strategies, the app has the option to sync automatically. If [auto-sync](auto_sync.md)
     6  is configured, the new resources manifests will be applied automatically -- as soon as a difference
     7  is detected.
     8  
     9  !!! note
    10      In all tracking strategies, any [parameter overrides](parameters.md) take precedence over the Git state.
    11  
    12  ## Helm
    13  
    14  Helm chart versions are [Semantic Versions](https://semver.org/). As a result, you can use any of the following version ranges:
    15  
    16  | Use Case | How | Examples |
    17  |-|-|-|
    18  | Pin to a version (e.g. in production) | Use the version number | `1.2.0` |
    19  | Track patches (e.g. in pre-production) | Use a range | `1.2.*` or `>=1.2.0 <1.3.0` |
    20  | Track minor releases (e.g. in QA) | Use a range | `1.*` or `>=1.0.0 <2.0.0` |
    21  | Use the latest (e.g. in local development) | Use star range |  `*` or `>=0.0.0` |
    22  | Use the latest including pre-releases | Use star range with `-0` suffix |  `*-0` or `>=0.0.0-0` |
    23  
    24  [Read about version ranges](https://www.telerik.com/blogs/the-mystical-magical-semver-ranges-used-by-npm-bower)
    25  
    26  !!! note
    27      If you want Argo CD to include all existing prerelease version tags of a repository in the comparison logic, you explicitly have to add a prerelease `-0` suffix to the version constraint. As mentioned `*-0` will compare against prerelease versions in a repository, `*` will not. The same applies for other constraints e.g. `>=1.2.2` will **not** compare prerelease versions vs. `>=1.2.2-0` which will include prerelease versions in the comparison.
    28  
    29  [Read about prerelease version comparison](https://github.com/Masterminds/semver?tab=readme-ov-file#working-with-prerelease-versions)
    30  
    31  ## Git
    32  
    33  For Git, all versions are Git references but tags [Semantic Versions](https://semver.org/) can also be used:
    34  
    35  | Use Case | How | Notes |
    36  |-|-|-|
    37  | Pin to a version (e.g. in production) | Either (a) tag the commit with (e.g. `v1.2.0`) and use that tag, or (b) using commit SHA. | See [commit pinning](#commit-pinning). |
    38  | Track patches (e.g. in pre-production) | Use a range (e.g. `1.2.*` or `>=1.2.0 <1.3.0`)                                           | See [tag tracking](#tag-tracking) |
    39  | Track minor releases (e.g. in QA) | Use a range (e.g. `1.*` or `>=1.0.0 <2.0.0`)                                             | See [tag tracking](#tag-tracking) |
    40  | Use the latest (e.g. in local development) | Use `HEAD` or `master` (assuming `master` is your master branch).                        | See [HEAD / Branch Tracking](#head-branch-tracking) |
    41  | Use the latest including pre-releases | Use star range with `-0` suffix | `*-0` or `>=0.0.0-0` |
    42  
    43  
    44  ### HEAD / Branch Tracking
    45  
    46  If a branch name or a symbolic reference (like HEAD) is specified, Argo CD will continually compare
    47  live state against the resource manifests defined at the tip of the specified branch or the
    48  resolved commit of the symbolic reference.
    49  
    50  To redeploy an app, make a change to (at least) one of your manifests, commit and push to the tracked branch/symbolic reference. The change will then be detected by Argo CD.
    51  
    52  ### Tag Tracking
    53  
    54  If a tag is specified, the manifests at the specified Git tag will be used to perform the sync
    55  comparison. This provides some advantages over branch tracking in that a tag is generally considered
    56  more stable, and less frequently updated, with some manual judgement of what constitutes a tag.
    57  
    58  To redeploy an app, the user uses Git to change the meaning of a tag by retagging it to a
    59  different commit SHA. Argo CD will detect the new meaning of the tag when performing the
    60  comparison/sync.
    61  
    62  But if you're using semantic versioning you can set the constraint in your service revision
    63  and Argo CD will get the latest version following the constraint rules.
    64  
    65  ### Commit Pinning
    66  
    67  If a Git commit SHA is specified, the app is effectively pinned to the manifests defined at
    68  the specified commit. This is the most restrictive of the techniques and is typically used to
    69  control production environments.
    70  
    71  Since commit SHAs cannot change meaning, the only way to change the live state of an app
    72  which is pinned to a commit, is by updating the tracking revision in the application to a different
    73  commit containing the new manifests. Note that [parameter overrides](parameters.md) can still be set
    74  on an app which is pinned to a revision.
    75