Problem Statement

Currently, declaring harness_platform_gitops_applicationset requires translating the entire ApplicationSet specification into nested HCL schema blocks. Argo CD ApplicationSets natively rely on YAML and often incorporate embedded Go/Helm templating syntax (e.g., conditional blocks like {{- if .baseValuesPath }}). Translating these constructs into pure HCL is rigid, error-prone, and adds unnecessary friction when translating back to YAML under the hood.

Proposed Solution

Introduce an optional raw YAML attribute (e.g., yaml_body, spec_yaml, or manifest) to the provider resource. This would allow users to supply the ApplicationSet definition directly via Terraform's standard functions like file() or templatefile(), bypassing the need for extensive HCL translation.

Use Case Example

Configuring dynamic Helm value files with conditional Go templating inside an ApplicationSet:

YAML

valueFiles:

{{- if .baseValuesPath }}

- $values/{{ .baseValuesPath }}

{{- end }}

- $values/{{ .valuesPath }}

ignoreMissingValueFiles: true

Expressing this conditional syntax natively in Terraform HCL blocks is impractical. Supplying raw YAML via standard templatefile() preserves native Argo capabilities.

Key Benefits

Native Argo Compatibility: Allows teams to re-use existing Argo ApplicationSet YAML manifests directly without manual HCL refactoring.

Preserves Templating Logic: Eliminates schema conflicts when using Go/Helm template tags inside manifest blocks.