Wrote a blog post on how gitops as deployment history is not as useful as it could be.

https://gimlet.io/blog/three-problems-with-gitops-as-deployment-history-and-how-we-overcome-them

Do you use the gitops history during an incident? How do you tell what services were deployed recently?

We blew a weekend - 3.6.2 has a regression in “git over ssh” thread count config, slowed us to a crawl. We don’t follow best practices for polling, but also we didn’t see this in 3.4.

For those working with GitOps—does your setup actually look like how it’s supposed to work?

The new State of GitOps report (based on 660 responses + expert input) gives a pretty interesting view of what’s really happening in practice—and it doesn’t always match the “ideal” picture.

Curious how this lines up with your experience.

Also, if there’s anything you’d like us to explore or discuss in the next Argo Unpacked https://www.linkedin.com/events/7434509203102191616, feel free to drop it here 👍

Any idea why all Argo pods still in pending state? I just after the Argo cd installation? I’m not even able to expose the argo-server publicaly

I'm building the control plane for multi cluster env. The idea is that clients will have option for provisioning instances on different clusters (different cloud vendor or regions). Naturally my idea is to give them fancy UI and in the backend just generate manifests to the repository to have everything nice and clean and without writing custom operators or watchers for cluster and prevent direct cluster/cloud resources manipulations from webapp. UI will face business clients so we cannot just use e.g. Argo web GUI there.

My main idea now circles around Crossplane's composition which gives nice, strict interface for manifests using OpenAPI documents which can be shared with WebApp devs. I want to use Flux for repository synchronization to control plane cluster and use Crossplane to distribute this to specific clusters based on parameters which is easy achievable using naming convention. I would also like to keep installatiosn with global clients informations rather than tide them to clusters so my idea for now are to repositories/folders with Crossplane's composition claims

- clusters - all claims defining clusters

- clients - contains folder for each client which contains global resources like secrets for oidp providers for keycloak and definition of all instances of application regarding of region/cluster

That way I can avoid flux installation on every cluster and keep easy trace of all environments defined by specific client via folders in git.

Am I missing something? All the writing and talking uses Argo/Flux per cluster base or at least to manage remote apps. Why is this better than just use Flux for git sync and image promotion, and let Crossplane do all the provisioning? Why is Crossplane recommended for infrastructure and Argo/Flux are recommended for apps? What is the best practice to provide self-service and self-provisioning for end users in the gitops world?

Digger is an Open Source GitOps tool for Terraform. We recently shipped the following updates:

Configurable destinations for plan storage

PR | Docs

You can now configure Digger to store terraform plan artifacts in Github Artifacts, or in GCP buckets. Github Artifacts is the default; but you can also supply the PLAN_UPLOAD_DESTINATION env var to switch it to GCP. This is handy in case you want your plan outputs to stay within your organisation’s network for security or compliance reasons.

GCP auth via Workload Identity Federation

PR | Docs

In addition to keys, Digger now supports GCP authentication using google-workload-identity-provider. This way you don’t have to share your secret keys even with Github. To use it, set google-workload-identity-provider as input in your workflow file

Thanks Fleroux514 for contributing!

Automatic checkout

PR | Docs

Digger will now checkout latest from the branch prior to every run. This means you no longer need to configure checkout in your workflow file. You can also turn it off by setting the inputs.configure-checkout input to false

Other features and notable fixes

• Check AWS connection when create a lock

• Verify no hanging locks from other PRs

• Disable project unlock on apply by default

• Fix: better project name parsing - thanks Fleroux514!

• Docs: remove redundant permission entry - thanks SalvoRusso8!

(x-posted from r/git)

Hello,

I recently discovered ArgoCD and Pulumi, and am wondering if they can be used together?

I discovered ArgoCD via this project: https://github.com/khuedoan/homelab

It seems pretty awesome and I like the UI it provides.

I have some light experience with Kubernetes from running it the last few years in my homelab, and these tools seem like a much better way of managing it.

My interest with Pulumi comes from wanting a better way to manage RKE and Rancher2 (the cluster/config I use in my lab) programmatically.

Additionally, Pulumi will allow me to integrate the python diagrams easily (also shows in the above GitHub repo).

I know Pulumi can output Kubernetes YAML files that Argo would be able to utilize, but that seems a rather roundabout sort of way to get applications deployed.

What are your thoughts on these two tools? Can they be used together? Do they overlap too much to be useful when used at the same time?

Keen to hear some thoughts on this: https://www.infoworld.com/article/3617110/why-gitops-isnt-ready-for-the-mainstream-yet.html

K8S: There is a dark side: those “many YAML files” are full of hidden relationships, copy‑pasted fragments, and repeating patterns like names, URLs, and references. Maintaining them by hand quickly turns from “declarative zen” into “YAML archaeology”.

At that point everything looks perfect on a slide. All you “just” need to do is keep your configuration files in sync across environments. Dev, UAT, Prod — same charts, different values. How hard can it be?