argocd Application: Support kustomize patch values

[mcbenjemaa]

Summary

What change you think needs making.

A new patching approach for arogcd Application with kustomize.

Motivation

Please give examples of your use case, e.g. when would you use this.

Managing many platforms that essentially use almost the same applications is somehow cumbersome with apps of apps pattern or via a helm chart. (We want to avoid DRY as mush as possible!)
Using kustomize to build a common base for all platforms is really better and consistent.
All our members should know the Application manifests very well, and thus can apply patches more easily.

Proposal

How do you think this should be implemented?

Adding a field to ApplicationSourceHelm so that kustomize users get the benifet of using it to apply patches.

Check my demo repo: https://github.com/mcbenjemaa/argocd-apps

[jsinme]

+1

[pc-tzimmerman]

Another use case:

If someone uses the PR generator & Git generator against the same Kustomize overlay, they may wish to patch the PR generator's Deployment name so that the PR container can be deployed alongside the normal container and otherwise use the same Service, ServiceAccount, etc.

Currently you can do this by passing nameSuffix to the PR generator. But then, you duplicate all the other resources too. Including the Service, ServiceAccount, etc.

[r0bj]

Another use case is to use kustomize to change ingress host which is currently not possible without a patch (kubernetes-sigs/kustomize#347).
For example:

$ cat ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: test.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              name: http

$ cat kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ingress.yaml
patches:
- target:
    kind: Ingress
    name: test
  patch: |
    - op: replace
      path: /spec/rules/0/host
      value: new-host.example.com

$ kustomize build
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: new-host.example.com
    http:
      paths:
      - backend:
          service:
            name: test
            port:
              name: http
        path: /
        pathType: Prefix

Note: Ingress host test.example.com was replaced with new-host.example.com.

[otherguy]

Similar usecase to @r0bj, I would like to add annotations to existing objects.

[crenshaw-dev]

Adding a field to ApplicationSourceHelm so that kustomize users get the benifet of using it to apply patches.

I think I'd wanna do this at the top level so you can apply patches to more than just Helm sources.

[crenshaw-dev]

I could imagine something like this, basically borrowing patches from Kustomize:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapps
spec:
  generators:
  - pullRequest:
      github:
        owner: myorg
        repo: myrepository
  template:
    spec:
      patches:
      - target:
          kind: Ingress
        patch: |-
          - op: replace
            path: /spec/rules/0/host
            value: '{{branch}}.example.com'

[crenshaw-dev]

PoC of that ^ #14648

And a similar feature at the ApplicationSet instead of the Application level: #14893

[joebowbeer]

Fixed by the #14648 and #14893 ?

[crenshaw-dev]

@joebowbeer not exactly, I misspoke in my comment above saying #14646 was a PoC of my proposed spec. I think OP wants the patches to be able to apply to any source type, not just kustomize. Similar request here: #16352

[Jojoooo1]

This feature would help a lot!

[TomMaSS]

+1
will be happy to see patch in provider

[NiklasRosenstein]

Would love to see the patches field on an Application pointing to a Helm chart for its source.