feat: infer app dependencies for change-based rendering

[szhekpisov-katanox]

Adds --infer-app-dependencies (default false): infers each application's local-repo file dependencies (spec.source.path and helm.valueFiles, including $ref values for remote charts) and renders it only when those files change. Opt-in, and unioned with the existing watch-pattern / manifest-generate-paths annotations. ApplicationSets bypass the files-changed filter so their generated Applications are filtered instead.

It requires no changes to the source repos holding your ArgoCD Applications/ApplicationSets. Fewer applications to render means faster runs.

Result: reduced execution time from 4m30s to 1m30s on 130 ArgoCD Applications.

Combine with --watch-if-no-watch-pattern-found=false to render only affected applications.

---

Originally submitted as a combined PR; split per review. The other changes now live in:

• feat: --skip-appset-generation-errors to tolerate ungeneratable ApplicationSets #453 — --skip-appset-generation-errors
• feat: bundle k3d binary + explicit kubeconfig merge for --cluster=k3d #454 — bundle k3d binary + explicit kubeconfig merge

[dag-andersen]

Hi @szhekpisov-katanox

Thank you so much for the PR. I really appreciate new people wanting to contribute.

This is a fairly big functional change that combines multiple independent changes in one PR. That makes it harder to review, test, and evaluate each part separately.

Would you mind splitting this into maybe 3 PRs?

• Change-based application rendering with --infer-app-dependencies
• ApplicationSet error tolerance with --skip-appset-generation-errors
• k3d image/runtime changes, including adding the k3d binary and explicit kubeconfig merge

That way we can evaluate, test, and merge them independently.

[szhekpisov-katanox]

Hi @dag-andersen , thank you for your prompt response, I've splited this PR into three, all of them are now available for review.

And thank you very much for this tool, it's very useful, convenient and well-thought!

[dag-andersen]

Hi @szhekpisov-katanox, sorry for the late answer. I am on vacation 🏝️

I have been thinking about this a bit, and wanted to ask: is this feature not mostly the same as automatically injecting the argocd.argoproj.io/manifest-generate-paths annotation on Applications at runtime?

If so, I think that could be a simpler implementation. Instead of adding a separate dependency inference and matching path, we could add something like --auto-add-manifest-generate-paths, and when enabled we automatically add the annotation to Applications that do not already have watch-pattern or manifest-generate-paths.

That way we can reuse the existing manifest-generate-paths behavior instead of maintaining a second implementation of similar logic.

What do you think about changing the implementation in that direction? :)

[szhekpisov-katanox]

Hi @szhekpisov-katanox, sorry for the late answer. I am on vacation 🏝️

I have been thinking about this a bit, and wanted to ask: is this feature not mostly the same as automatically injecting the argocd.argoproj.io/manifest-generate-paths annotation on Applications at runtime?

If so, I think that could be a simpler implementation. Instead of adding a separate dependency inference and matching path, we could add something like --auto-add-manifest-generate-paths, and when enabled we automatically add the annotation to Applications that do not already have watch-pattern or manifest-generate-paths.

That way we can reuse the existing manifest-generate-paths behavior instead of maintaining a second implementation of similar logic.

What do you think about changing the implementation in that direction? :)

Thanks — enjoy the vacation!

I love that we're after the same goal here (no repo changes needed - inject/infer at runtime), so it really comes down to what the matcher can express. I think the implementation is less duplicated than it seems: watch-pattern, manifest-generate-paths, and the inferred paths all feed into the same filterByFilesChanged and share the same anyFileChangedUnderPaths comparator. Inference isn't a second matcher, it's just a third source of candidate paths into the existing one.

The reason I don't think a plain --auto-add-manifest-generate-paths fully covers it: the annotation's native path resolution only joins relative paths against spec.source.path. It has no notion of $ref/..., so it can't track Helm valueFiles that live outside the source path, or local $ref value sources feeding a remote chart, which is a big part of what the inference resolves. To inject an annotation that captured those, we'd still have to compute the paths with the same inferLocalWatchPaths logic and just write pre-resolved absolute paths into the annotation, which bypasses the annotation resolver anyway, so it's about the same amount of code.

There's also the ApplicationSet handling (generate the set, filter the generated children) that's needed regardless of which matcher we use.

Happy to rename the flag or reshape the API if that helps, but I'd lean toward keeping the inference so we don't lose the value-files / $ref coverage.