Multi-Source Support Proposal 1: sourceHydrator.drySources NOTE: This is my current recommendation. Pros: Parallel to source/sources UX Parallel to source/sources implementation Cons:

Proposal: GitOps Promotion/Rollback Tool This proposal describes an opinioned set of API/tools to manage change promotion and reversion in a GitOps environment. Open Questions Where will the code reside? This proposal includes several new controllers which should be able to run independently of Argo CD. It's likely that the code should live in one or more repositories separate from Argo CD itself. Will Argo CD provide out-of-the-box integration with this tooling? We believe Argo CD users would benefit greatly from the features provided by this system. But it's possible that the functionality could be offered via add-ons, including adjacent controllers and UI extensions.

For an on-paved road service, this is the only file in their deployment repo: apiVersion: mycompany.com/v1alpha1 kind: WebService metadata: name: my-service spec: version: 13 # helm chart version # everything here goes into values.yaml values: # This is NOT an untyped object. The fields are defined and enforced with a JSON schema.

Major concepts: cluster cachecache sync kubectl semaphore project cache orphaned resource index

Manifest Hydrator This proposal describes a feature to make manifest hydration (i.e. the "rendered manifest pattern") a first-class feature of Argo CD. Open Questions The sourceHydrator field is mutually exclusive with the source and the sources field. Should we throw an error if they're both configured, or should we just pick one and ignore the others? How will/should this feature relate to the image updater? Is there an opportunity to share code, since both tools involve pushing to git? Should we enforce a naming convention for hydrated manifest branches, e.g. argo/...? This would make it easier to recommend branch protection rules, for example, only allow pushes to argo/* from the argo bot. Summary Manifest hydration tools like Helm and Kustomize are indispensable in GitOps. These tools transform "dry" (Don't Repeat Yourself) sources into plain Kubernetes manifests. The effects of a change to dry sources are not always obvious. So storing only dry sources in git leaves the user with an incomplete and confusing history of their application. This undercuts some of the main benefits of GitOps.