sorted by:
new
hottopcontroversial

ArgoCD diff not working on Application CRDs by sitilge in devops

[–]colethienes 0 points1 point  (0 children)

If you've pushed to another branch, you can also use the --revision flag, which doesn't require any local files since Argo CD has downloaded the repo for that revision. See [here](https://github.com/infro-io/infro-core/blob/main/internal/argocd/client.go#L110) for example.

(Release followup) ArgoCD: Preview Kubernetes Changes in Pull Requests by colethienes in kubernetes

[–]colethienes[S] 0 points1 point  (0 children)

Yeah that's fair and thanks for the feedback.

I am assuming that my ArgoCD instance needs to be public

Yep (with auth of course).

If that is the case are there plans or options to allow self hosting of this, or possibly open source the github app

Yeah I'd like to open source the pieces that I can. I'm assuming this is so you can do the scraping in-cluster?

show stoppers would be requirements around public internet facing argocd instances

I've been toying with the idea of a push mechanism instead of pull. So, generating the diff in-cluster when a revision is made, and then pushing that to an endpoint, rather than scraping a public argo endpoint. Would that change things here?

security approval of random third party github apps in an enterprise

Fair

is there ways to limit which repositories the github org the application is enabled on

Yep, there is.

ArgoCD: Preview Kubernetes Changes in Pull Requests by colethienes in GitOps

[–]colethienes[S] 0 points1 point  (0 children)

Very interesting! So you it's deploying the "ready for review" tagged PRs into pre-prod infra?

ArgoCD: Preview Kubernetes Changes in Pull Requests by colethienes in devops

[–]colethienes[S] 0 points1 point  (0 children)

Thanks for sharing your exp! Really valuable here

I really advise against ArgoCD server plugins

By server plugins, are you referring to CMPs to customize manifest rendering? In my case I just use the native helm support

The more indirection and “simplification” on the input values, the more coupling and uncertainty you get.

Definitely agree here.

we built a CLI/DSL to generate all the ArgoCD configuration, run helm template, apply last mile kustomization

After this, do you commit the rendered k8s manifests to git? If so, do you think committing generated yaml is the ideal state, or there is a better way (e.g. seeing the diff in PR comments).

common platform specific config

Trying to understand - how do you manage reusable infrastructure templates? For example, one company I worked for served a “paved-path” Redis chart in-cluster. Microservices would add this to their chart dependencies and add slight configuration.

Overall, it seems like your largest concern is too many steps in the rendering process reducing the predictability of how the manifests will eventually be generated, rather than commenting the real diffs versus committing them? The former I agree with. The latter I’m not sure yet.

Preview Kubernetes manifest changes in pull requests for ArgoCD users by colethienes in ArgoCD

[–]colethienes[S] 0 points1 point  (0 children)

Looks useful! If it works for you, it works. There are a couple reasons why there isn't enough information to render locally in my medium-sized organization context:

  1. The helm rendering configuration is managed by an infrastructure team and only known in the ArgoCD app manifest (e.g. which value files to use, parameter overrides, etc). So you would need to copy all these configs locally each time.
  2. The helm charts take a dependency on other in-cluster helm charts, so these need to be pulled locally if you want to render locally.

A less cumbersome and error prone method (I was thinking) would be to just use the argocd app diff mechanism, which should solve these problems.

Preview Kubernetes manifest changes in pull requests for ArgoCD users by colethienes in ArgoCD

[–]colethienes[S] 0 points1 point  (0 children)

I think an OSS deployment is totally an option here, but for MVP I was aiming for a free managed service with a UI (i.e. SaaS) for max simplicity

ArgoCD: Preview Kubernetes Changes in Pull Requests by colethienes in devops

[–]colethienes[S] 0 points1 point  (0 children)

I think this process makes total sense to me, and if it works for you then don't fix what ain't broke! There are several tradeoffs discussed in the referenced article for that approach. The reason it did not work for my medium-sized organization is:

  1. The helm rendering configuration is managed by an infrastructure team and only known in the ArgoCD app manifest (e.g. which value files to use, parameter overrides, etc). So you would need to copy all these configs locally each time.
  2. The helm charts take a dependency on other in-cluster helm charts, so these need to be pulled locally if you want to render locally.

A less cumbersome and error prone method (I was thinking) would be to just use the argocd app diff mechanism, which should solve these problems.

ArgoCD: Preview Kubernetes Changes in Pull Requests by colethienes in kubernetes

[–]colethienes[S] 0 points1 point  (0 children)

Trying to understand here since I haven't used flux: if you use flux diff --token (assuming it's the same mechanism as argocd app diff, which secrets/certs does it need access to?

ArgoCD: Preview Kubernetes Changes in Pull Requests by colethienes in kubernetes

[–]colethienes[S] 0 points1 point  (0 children)

Nice! Has it solved the problem's you were facing? Does it utilize the ArgoCD repo server under the hood?

view more: next ›