github.com/argoproj/argo-cd/v3@v3.2.1/docs/operator-manual/upgrading/2.11-2.12.md (about)

     1  # v2.11 to 2.12
     2  
     3  ## Cluster secret scoping changes
     4  
     5  From Argo CD 2.12, there have been some changes to the use of cluster secrets where a `project` is a non-empty value. 
     6  Previously, an `Application` or `ApplicationSet` would use any cluster secret matching the URL of the `repoUrl` field. 
     7  From 2.12, we now check to see whether the project field of an application _also_ matches the project field of the cluster 
     8  secret. What this means is that if you have a cluster secret scoped to `project-a`, an application scoped to `project-b`
     9  can no longer make use of the secret. If you have a cluster secret that's intended to be used by applications in multiple 
    10  projects, you need to **unset** the `project` field.
    11  
    12  This also applies when using the Git generator in applicationsets; since an applicationset is not scoped to a particular
    13  project any cluster secrets it makes use of also needs to be globally scoped (i.e. any secret needs to have an unset 
    14  `project`).
    15  
    16  ## Upgraded Helm Version
    17  
    18  Note that bundled Helm version has been upgraded from 3.14.4 to 3.15.2.
    19  
    20  ## Image Registry Change for `redis` and `haproxy`
    21  
    22  Argo CD 2.12 upgraded its [upstream redis-ha Helm chart](https://artifacthub.io/packages/helm/dandydev-charts/redis-ha/)
    23  version from 4.22.3 to 4.26.6.
    24  
    25  As part of the upgrade, the image registry for `redis` and `haproxy` was changed from DockerHub to ECR.
    26  
    27  Make sure that the registry change will work for your environment. One example of a problem would be that your 
    28  environment can use Cosign to verify the image signature for DockerHub but not for ECR. You would need to make sure your 
    29  Image Validation policy includes the AWS ECR as an approved registry. Please validate that the registry change is
    30  acceptable before upgrading.
    31  
    32  ## Server-Side Apply Management of ApplicationSet Fields
    33  
    34  ### Summary
    35  
    36  If you are using server-side apply with multiple field managers to manage a single `selector` or `labelSelector` field 
    37  in an ApplicationSet, that field management must be changed to be atomic starting with 2.12. 
    38  
    39  ### Details
    40  
    41  Argo CD 2.12 upgraded its controller-gen version from 0.4.1 to 0.14.0. As part of that change, several ApplicationSet
    42  CRD fields now have `x-kubernetes-map-type: atomic`.
    43  
    44  Each of the affected fields is a label selector with two child keys: `matchLabels` and `matchExpressions`.
    45  
    46  Prior to this change, two field managers could manage the `matchLabels` and `matchExpressions` fields independently.
    47  Starting with the 2.12 CRD, a single field manager must manage both of those fields. This behavior is in line with the
    48  upstream behavior of the label selector struct.
    49  
    50  See the [Kubernetes server-side apply merge strategy docs](https://kubernetes.io/docs/reference/using-api/server-side-apply/#merge-strategy)
    51  for more information about the fields' behavior.
    52  
    53  The affected ApplicationSet fields are the following (jq selector syntax):
    54  
    55  * `.spec.generators[].selector`
    56  * `.spec.generators[].cluster.selector`
    57  * `.spec.generators[].clusterDecisionResource.labelSelector`
    58  * `.spec.generators[].matrix.generators[].selector`
    59  * `.spec.generators[].merge.generators[].selector`