Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Add lever to hydrate ApplicationSet-managed Applications with argocd appset generate #73

Open
seanturner026 opened this issue Dec 10, 2024 · 2 comments
Labels
feature-request Feature Request

Comments

@seanturner026
Copy link

seanturner026 commented Dec 10, 2024

ArgoCD recently added a really handy cli upgrade in the form of argocd appset generate $appset_name.yaml -o yaml.

https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_appset_generate/

This takes one's ApplicationSet and hydrates or renders all of the Application manifests that would be created if the ApplicationSet were to be deployed. This command greatly improves the ApplicationSet development feedback loop in two ways:

  1. One can run the CLI command and see what manifests are going to be changed if they're just making yaml templating changes
  2. Alternatively one can also confirm that an Application is being generated properly e.g. I'm using a git generator and I add a new directory that's globbed by the wild card.

Currently the ArgoCD Diff Preview renders new Applications when they're added in a PR. I propose that the ArgoCD Diff Preview by default render the Applications that are created by an ApplicationSet via the CLI.

I think it could also be helpful to have the option of disable this behavior (e.g. argocd appset generate -o yaml functionality) with an environment variable.

Consider your example from: https://github.com/dag-andersen/argocd-diff-preview/blob/ded37e62b69aa26289d3aae3e8a9d82b34fcba14/examples/helm/applications/my-app-set.yaml

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
  - list:
      elements:
      - name: dev
      - name: prod
      - name: staging
  template:
    metadata:
      name: 'my-app-set-{{.name}}'
    spec:
      project: default
      destination:
        name: in-cluster
        namespace: default
      sources:
        - repoURL: https://github.com/dag-andersen/argocd-diff-preview
          ref: local-files
        - path: examples/helm/charts/myApp
          repoURL: https://github.com/dag-andersen/argocd-diff-preview
          helm:
            valueFiles:
              - $local-files/examples/helm/values/my-app-set.yaml

If I were to open a PR adding a new enviornment...

      - name: dev
      - name: prod
      - name: staging
+     - name: uat

I would expect the ArgoCD Diff Generator to render an Application for UAT.

@dag-andersen dag-andersen added the feature-request Feature Request label Dec 14, 2024
@dag-andersen
Copy link
Owner

dag-andersen commented Dec 21, 2024

Hi, @seanturner026, sorry for the late answer.

I thought of the same thing! and I agree using the argocd appset generate command would be great 🚀

However, I’ve already tried implementing it and encountered some strange CLI errors related to networking. I decided to pause for now since there were other, more pressing features to prioritize. But I definitely plan to revisit it in the future. Of course, others are welcome to give it a try in the meantime!

But I am a bit confused by the example you’re giving because if you add the - name: uat line, it would render the application for UAT - but perhaps I’m misunderstanding the example? :)

I just did it locally, and it renders this ⬇️

Argo CD Diff Preview

Summary:

 /dev/null => target/my-app-set-uat | 88 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)
Diff:
diff --git target/my-app-set-uat target/my-app-set-uat
new file mode 100644
index 0000000..12fcce7
--- /dev/null
+++ target/my-app-set-uat
@@ -0,0 +1,88 @@
+---
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/instance: my-app-set-uat
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/name: myApp
+    app.kubernetes.io/version: 1.16.0
+    argocd.argoproj.io/instance: my-app-set-uat
+    helm.sh/chart: myApp-0.1.0
+  name: super-app-name
+  namespace: default
+spec:
+  ports:
+  - name: http
+    port: 80
+    protocol: TCP
+    targetPort: http
+  selector:
+    app.kubernetes.io/instance: my-app-set-uat
+    app.kubernetes.io/name: myApp
+  type: ClusterIP
+
+---
+apiVersion: v1
+automountServiceAccountToken: true
+kind: ServiceAccount
+metadata:
+  labels:
+    app.kubernetes.io/instance: my-app-set-uat
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/name: myApp
+    app.kubernetes.io/version: 1.16.0
+    argocd.argoproj.io/instance: my-app-set-uat
+    helm.sh/chart: myApp-0.1.0
+  name: super-app-name
+  namespace: default
+
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.kubernetes.io/instance: my-app-set-uat
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/name: myApp
+    app.kubernetes.io/version: 1.16.0
+    argocd.argoproj.io/instance: my-app-set-uat
+    helm.sh/chart: myApp-0.1.0
+  name: super-app-name
+  namespace: default
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app.kubernetes.io/instance: my-app-set-uat
+      app.kubernetes.io/name: myApp
+  template:
+    metadata:
+      labels:
+        app.kubernetes.io/instance: my-app-set-uat
+        app.kubernetes.io/managed-by: Helm
+        app.kubernetes.io/name: myApp
+        app.kubernetes.io/version: 1.16.0
+        helm.sh/chart: myApp-0.1.0
+    spec:
+      containers:
+      - image: nginx:1.16.0
+        imagePullPolicy: IfNotPresent
+        livenessProbe:
+          httpGet:
+            path: /
+            port: http
+        name: myApp
+        ports:
+        - containerPort: 80
+          name: http
+          protocol: TCP
+        readinessProbe:
+          httpGet:
+            path: /
+            port: http
+        resources: {}
+        securityContext: {}
+      securityContext: {}
+      serviceAccountName: super-app-name
+

@seanturner026
Copy link
Author

seanturner026 commented Dec 22, 2024

But I am a bit confused by the example you’re giving because if you add the - name: uat line, it would render the application for UAT - but perhaps I’m misunderstanding the example? :)

Was saying in addition to the Service and other resources in the diff you've shared, an Application CRD would also be rednered for uat, similar to how if an Application manifest was being used (and a uat manifest was added) rather than an ApplicationSet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Feature Request
Projects
None yet
Development

No branches or pull requests

2 participants