Feat | Support diffs with live environments

[jgautheron]

Adds a new comparison mode that diffs PR changes against live deployed state from a remote ArgoCD instance, rather than comparing against a base branch.

• New CLI flags: --compare-live, --live-argocd-url, --live-argocd-token, --live-argocd-insecure
• Fetches live manifests via ArgoCD REST API (/api/v1/applications/{app}/manifests)
• Matches PR applications to live applications by name
• Applies ignoreDifferences from application spec and removes ArgoCD tracking annotations for clean diffs
• Integration tests spin up a real Kind cluster with ArgoCD to validate the feature

[jgautheron]

@dag-andersen any interest in introducing that feature to the repo?

[dag-andersen]

any interest in introducing that feature to the repo?

This is a tricky one!

First of all, thank you for the PR and the effort you've put into this!
I appreciate that you've included integration tests as well 😄

Whether to include this feature depends on whether there's broader interest from users. I'd suggest creating a feature request issue so we can gauge interest through upvotes and comments from the community.

I do want to share some thoughts on this approach, just so you know where I'm coming from:

• From a process perspective: I'd argue that if you have auto-sync enabled, you don't need to compare against live state - comparing against main is sufficient because main is the live state (or will be shortly after merge). Personally, I believe having auto-sync disabled is an anti-pattern in GitOps, and I'm hesitant to add features that make anti-patterns easier.
• From a technical perspective: Comparing to live state makes the tool's output non-deterministic. If the cluster state changes between runs, you get different results. This makes the diff hard to trust during code review. It also introduces ambiguity: if an application is out-of-sync, should the diff compare against the "not-yet-synced" desired state, or against the manifests that were applied last time the app was synced?

I've just now written more about this in the Design Philosophy docs. And it is also briefly mentioned in the ArgoCon talk from 2024

That said, I'm also not a fan of open source maintainers being gatekeepers who limit a tool's user base based on philosophical ideals. If there's genuine demand for this feature, I'm open to discussing it further. Let's see what the community thinks!

[jgautheron]

Hey @dag-andersen appreciate you considering this feature.
Posted a feature request, let's see!