While garden is happy to apply the kubernetes manifest, it normally insists on there being at least some kind of pod (

serviceResource

in the old

kubernetes

module, and

defaultTarget

in the new actions). It becomes cumbersome if the deployed thing is not a pod, but just a CRD-defined manifest, with a separately-deployed controller taking care of the actual pod. Would be nice if such workflows were nicely supported 🙂

Hey @lively-actor-89932, we already support applying arbitrary manifests e.g. this Dapr component CRD is perfectly valid

yaml
kind: Deploy
type: kubernetes
name: azure-key-vault-secret-store
description: Dapr secret store to read Azure Key Vault secret
spec:
  manifests:
    - apiVersion: dapr.io/v1alpha1
      kind: Component
      metadata:
        name: azure-key-vault-secret-store
      spec:
        type: secretstores.azure.keyvault
        version: v1
        metadata:
        - name: vaultName
          value: ${actions.deploy.my-pulumi-azure-key-vault.outputs.keyVaultName}
        - name: azureTenantId
          value: ${actions.deploy.my-pulumi-azure-key-vault.outputs.tenantId}
        - name: azureClientId
          value: ${actions.deploy.my-pulumi-azure-key-vault.outputs.clientId}
        - name: azureClientSecret
          secretKeyRef:
            name: ${actions.deploy.my-pulumi-azure-key-vault.outputs.secretName}
            # The stringData field is never output when reading from the API.
            key: client-secret