Expand Infisical secret references when reading Fleet-OPS root (OPS-818)

[jaywedgeworth22]

Refs OPS-818

Summary

Updates the Infisical export used by Fleet-OPS root CI so that secret values stored as bare references (for example ${prod.some-folder.NAME}) are returned already resolved, and so that any reference that still cannot be resolved halts the export instead of being injected into the workflow as if it were the credential.

Functional changes

• Reference expansion requested from Infisical (scripts/infisical-fetch.mjs): the raw-secrets list call now sets expandSecretReferences=true (previously false). A secret whose stored value is a bare reference now comes back as the referenced value. Expanding requires the reading identity to also be able to read the referenced folder.
• Fail-closed handling for unresolved references: a new isUnresolvedReference helper detects values that are still a single whole-value ${...} reference (leading/trailing whitespace ignored; embedded references such as prefix-${...} or ${...}-suffix are not treated as unresolved).
• Unresolved keys are never exported: when a value is still a bare reference, the key is collected, an ::error:: line names the key only with guidance to check that the target exists and the CI identity can read the referenced folder, and the value is skipped — it is not written to GITHUB_ENV and not passed through masking or logging.
• Export aborts on unresolved references: after processing all names, if any unresolved references were found, run throws an error listing the affected key names (not values). This check runs before the existing missing-required-names error.
• Resolved values behave as before: they are masked and written to GITHUB_ENV normally.

Tests added

New scripts/infisical-fetch-expand.node-test.mjs covers:

• the list request includes expandSecretReferences=true;
• an unresolved reference fails the run, names the key, and never leaks the reference into the error, log, or GITHUB_ENV;
• a resolved value is written normally;
• isUnresolvedReference matches only whole-value bare references and rejects partial, plain, empty, and undefined inputs.

Review note

The automated review flagged [medium] that the task description is insufficient for business-logic validation; the description above documents the intended behavior (server-side expansion plus fail-closed export) for that validation.

[linear-code]

OPS-818

[kody-ai]

Kody Review Complete

Great news! 🎉
No issues were found that match your current review configurations.

Keep up the excellent work! 🚀

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​

[kody-ai]

🤔 Insufficient Task Context

I found a task linked to this PR, but it only contains minimal information (title only, no description or acceptance criteria). To perform a meaningful business rules validation, I need more details.

🔍 What I need to validate:

• Business requirements and acceptance criteria
• Expected behavior and business rules
• Edge cases and constraints to consider

💡 How to improve the task context:

• Add a description to the linked ticket
• Include acceptance criteria or business rules
• Describe the expected behavior after the change

⚠️ Important:

A task title alone is not sufficient to determine whether the implementation is correct or complete.

---

💡 This validation runs automatically only on the first review of a pull request. To run it again, comment @kody -v business-logic.