generate-gitops output is not round-trip compatible with gitops when string values contain `$`

[Brajim20]

Fleet version: v4.84.0-rc.2604222001
Found Fleet version: v4.84.0-rc.2604222001

💥 Actual behavior

When a string field value (e.g., VPP app display_name) contains a $ character followed by alphanumeric characters, the round-trip UI → generate-gitops → gitops is broken.

1. A value set via the Fleet UI (e.g., display_name: ($($U$J@) is stored in the DB.

2. fleetctl generate-gitops outputs this value literally into the yml file.

3. fleetctl gitops attempts to apply the file and interprets $U and $J as environment variable references, failing with:

4. No working escape mechanism found:

   • $$ produces more errors (5 instead of 2), as gitops treats $$ as a separate var reference
   • Single-quoting the value does not help
   • Double-quoting the value does not help
     No working escape was found: $$ produces more errors, and single/double quoting does not help.

---

UPDATE: @noahtalerman: this is how to escape:

(https://fleetdm.com/docs/configuration/yaml-files#variables:~:text=)-,can%20be%20escaped,-so%20it%27s%20not)

🛠️ Expected behavior

Update the error message:

* environment variable U not set; if you intended the literal string $U then please escape it as \$U.

🧑‍💻 Steps to reproduce

1. In the Fleet UI, set a string field (e.g., VPP app display_name) to a value containing $ followed by alphanumeric chars — e.g., ($($U$J@
2. Run fleetctl generate-gitops --dir /tmp/test-export --force
3. Run fleetctl gitops -f /tmp/test-export/fleets/<team>.yml --dry-run
4. Observe failure with environment variable "<X>" not set

🕯️ More info

Discovered while verifying #33106. Affects any text field that ends up in gitops yml output (display names, descriptions, URLs, passwords, queries, etc.).

[sgress454]

@Brajim20 You can work around this using regular yaml/json escaping, with a backslash:

display_name: (\$(\$U\$J@

[Brajim20]

@sgress454 yes, confirmed \$ works as the escape. I can update this ticket with those findings.

Would it be worth having generate-gitops emit a warning when it outputs a value containing $, letting the user know they'll need to escape it before running gitops? Something like the existing "Sensitive information was redacted" block in the generate-gitops output. That way users aren't surprised when the round-trip fails on apply.

[sgress454]

@sgress454 yes, confirmed \$ works as the escape. I can update this ticket with those findings.

Would it be worth having generate-gitops emit a warning when it outputs a value containing $, letting the user know they'll need to escape it before running gitops? Something like the existing "Sensitive information was redacted" block in the generate-gitops output. That way users aren't surprised when the round-trip fails on apply.

I think I missed that generate-gitops was in the mix here. It should be able to do this escaping for you; I'll look into it