feat(hydrator): add inline parameter support to Source Hydrator (#24228)

[sangyeong01]

Summary

Add Helm support to Source Hydrator (alpha feature) to enable using Helm charts with environment-specific value files and parameters.

Currently, Source Hydrator only supports basic Git repository fields (repoURL, targetRevision, path) in the DrySource specification, making it impossible to use with Helm charts that require valueFiles, parameters, or other Helm-specific configurations.

This PR adds a Helm field to the DrySource type and updates the hydrator logic to properly handle Helm configurations, enabling teams to use Source Hydrator with Helm-based applications.

Closes #24228

Changes

• API: Added Helm *ApplicationSourceHelm field to DrySource type in pkg/apis/application/v1alpha1/types.go
• Logic: Updated controller/hydrator/hydrator.go to copy Helm configuration from DrySource to the hydrated ApplicationSource

Example Usage

Before (not supported):

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  sourceHydrator:
    drySource:
      repoURL: https://github.com/example/charts.git
      targetRevision: main
      path: my-chart
      # ❌ helm field not supported

After (now supported):

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  sourceHydrator:
    drySource:
      repoURL: https://github.com/example/charts.git
      targetRevision: main
      path: my-chart
      helm:  # ✅ Now works
        valueFiles:
          - values-prod.yaml
        parameters:
          - name: image.tag
            value: v1.2.3
        releaseName: my-release

Use Case

Many teams use Helm with environment-specific value files (e.g., values-dev.yaml, values-prod.yaml). Without this support, Source Hydrator cannot be used for Helm applications, limiting its adoption for teams that want to use both Helm and the hydration workflow.

Testing

• Manual testing with Helm chart and multiple value files
• Verified existing functionality remains unaffected
• Confirmed omitempty tag ensures backward compatibility

Future Work

• Add unit tests (will be included in follow-up PR)
• Update CRD schema (will be included in follow-up PR)
• Add documentation (will be included in follow-up PR)

Checklist

• Either (a) I've created an [enhancement proposal](https://github.com/argoproj/argo-cd/issues/new/choose) and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the release note).
• The title of the PR conforms to the [Title of the PR](https://argo-cd.readthedocs.io/en/latest/developer-guide/submit-your-pr/#title-of-the-pr)
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• I have signed off all my commits as required by [DCO](https://github.com/argoproj/argoproj/blob/master/community/CONTRIBUTING.md#legal)
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My build is green ([troubleshooting builds](https://argo-cd.readthedocs.io/en/latest/developer-guide/ci/)).
• My new feature complies with the [feature status](https://github.com/argoproj/argoproj/blob/master/community/feature-status.md) guidelines.
• I have added a brief description of why this PR is necessary and/or what this PR solves.
• Optional. My organization is added to USERS.md.
• Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

Notes

This PR focuses on the core API and logic changes. Follow-up PRs will include:

1. Unit and integration tests
2. CRD schema updates
3. Documentation updates
4. CLI/UI updates if needed

The changes are minimal and backward-compatible, using the omitempty JSON tag to ensure existing DrySource configurations continue to work without modification.

[bunnyshell]

❌ Preview Environment deleted from Bunnyshell

Available commands (reply to this comment):

• 🚀 /bns:deploy to deploy the environment

[codecov]

Codecov Report

❌ Patch coverage is 84.61538% with 2 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (master@e81872f). Learn more about missing BASE report.
⚠️ Report is 20 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/apis/application/v1alpha1/types.go	77.77%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #24277   +/-   ##
=========================================
  Coverage          ?   62.46%           
=========================================
  Files             ?      351           
  Lines             ?    49502           
  Branches          ?        0           
=========================================
  Hits              ?    30922           
  Misses            ?    15619           
  Partials          ?     2961           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[crenshaw-dev]

Thanks for the PR! I've marked it as draft while it's being iterated over.

I think we should add kustomize and directory fields at the same time for feature parity with the source field.

I don't think we can save CRD updates, tests, and docs for a follow-up PR. Those need to be part of the initial PR.

[crenshaw-dev]

Thanks for the changes! Can you add docs and e2e tests?

[sangyeong01]

@crenshaw-dev,
I’ve addressed all requested changes, including adding docs and e2e tests. Could you please take another look when you have a chance? Thanks!

[sangyeong01]

Looking good! Added a couple questions about tests.

Mind adding a note to docs/operator-manual/application.yaml that these fields are available? No need to copy the full spec from source, just add a note that the helm, kustomize, directory, and plugin fields are available.

Added a note in commit 607f7a0. The docs now mention that drySource.helm, drySource.kustomize, drySource.directory, and drySource.plugin fields are available and reference the source field sections above for the full spec.

[crenshaw-dev]

@sangyeong01, @emirot is gonna give this a local test, but code LGTM. Looking forward to getting it into 3.3!

[emirot]

I have added an ArgoCD helm application with your changes and I could see the helm chart got hydrated https://github.com/emirot/argocd-test-hydrator/tree/environments/dev/development

ArgoCD app:

project: default
destination:
  server: https://kubernetes.default.svc
  namespace: argocd
sourceHydrator:
  drySource:
    repoURL: https://github.com/emirot/argocd-test-hydrator
    targetRevision: HEAD
    path: hello-world
    helm:
      valueFiles:
        - values.yaml
      releaseName: my-release
  syncSource:
    targetBranch: environments/dev
    path: development

However in my case it looks like the app is in a infinite Hydrating state

@sangyeong01 what did I miss? Did you see that behavior?

[crenshaw-dev]

@emirot good catch! I proposed a fix here: sangyeong01#1

[sangyeong01]

@emirot good catch! I proposed a fix here: sangyeong01#1

Thanks for the fix! I tested this by deploying a local build . Before the fix, it was stuck in Hydrating state with repeated "reason":"spec.sourceHydrator differs" logs. After the fix, it reaches Hydrated and stays stable. Good to merge.

[crenshaw-dev]

Great! @sangyeong01 you can either merge my PR into your branch or copy/paste my code into this PR. :-)

[sangyeong01]

Thanks @crenshaw-dev ! I've merged your PR into my branch. The fix is now included in this PR.

[crenshaw-dev]

Great work, thanks so much! And thanks @emirot for the testing!

[juwon8891]

Thanks @sangyeong01

[sym-stiller]

Hey guys,

I was really looking forward to this feature, because I wanted to use a Helm chart with multiple values.yaml files in a hydrator app. The hydration works well, I can see that the manifests were rendered correctly to my hydration branch. But I noticed an issue with this feature: When ArgoCD tries to apply the manifests from my sync branch to the K8s cluster, ArgoCD renders the manifests on my sync branch again (by calling helm template)! This obviously fails with an error, since the manifests on my sync branch are already hydrated, and there is no Helm chart to template on this branch.

My AppSet looks like this:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
spec:
  generators: ...
  template:
    spec:
      sourceHydrator:
        drySource:
          repoURL: https://github.com/someRepo
          path: &path somePath # you can find a standard Helm chart and multiple values.yaml files here
          targetRevision: HEAD # dry branch
          helm:
            valueFiles:
              - values.yaml
              - values-{{.env}}.yaml
        hydrateTo:
          targetBranch: environments/{{.env}}-next # hydration branch
        syncSource:
          targetBranch: environments/{{.env}} # sync branch
          path: *path

As I said, hydration works fine. But when the time comes to sync this app to the cluster, I get a ComparisonError event with a message like this:

Failed to load target state: failed to generate manifest for source 1 of 1: rpc error: code = Unknown desc = Manifest generation error (cached): failed to execute helm template command: failed to get command args to log: `helm template . --name-template REDACTED--namespace REDACTED --kube-version 1.33 <api versions removed> --include-crds` failed exit status 1: Error: template: some/templatefile/in/my/chart.yaml:10:16: executing "some/templatefile/in/my/chart.yaml" at <.Values.some.value>: nil pointer evaluating interface {}.value Use --debug flag to render out invalid YAML

The event message looks like ArgoCD tries to hydrate the already hydrated manifests from the sync branch again before applying them. When I omit all helm: parameters from my app, everything can be synced as expected, so I suspect that this new behavior was introduced with the inline parameter support for Source Hydrator.

My environment:

1. ArgoCD v3.3.0-rc3
2. gitops-promoter v0.20.2
3. AKS cluster with K8s v1.33.5

Should I open a new issue for this bug? Have I misconfigured something, and there is no bug? Any help would be appreciated, since this is blocking us from rolling out gitops-promoter.

[crenshaw-dev]

@sym-stiller that definitely seems like a bug, can you open an issue?