Integrate .env secret bindings with param prompting

[Berlioz]

This PR centers around changes made to the handleSecret()/now ensureSecret() method invoked during param resolution. Formerly, handleSecret() only made sure that a Cloud Secret with a resource name matching the name of the Secret Param existed with a readable latest version.

Now:

1. It can use an alternative resource name and version identifier from the Secret Param, which has been merged into the Param object earlier in deployment by applyEnvSecretBindings().
2. It emits a string representing the secret binding which should be written to .env files. These strings are propagated up the call chain to prepare.ts, which has them inserted to .env files only if not present using the same mechanisms that currently write other params.
3. It logs an INFO-level notification in the case where the backing Cloud Secret already existed but no matching record in .env files existed, in which case we are basically "importing" a secret that already existed. Open to wording suggestions here, especially if we should specifically advise users to commit to version control.

Intended behavior after merging this PR on deploy:

• Secret Param exists, .env secret exists: applyEnvSecretBindings seamlessly overrides the Secret to look in the place specified by .env, which satisfies ensureSecret().
• Secret Param missing, .env secret exists: no-op; since defineSecret() was never called during discovery, no corresponding record exists in build.SecretEnvVars and applyEnvSecretBindings skips the .env secret.
• Secret Param exists, .env secret missing: ensureSecret() checks to see whether a Secret resource exists at the "default" secret location. If so, it logs a warning and writes that default secret to .envs. Otherwise, it helps the user create a secret and upon success writes it to .env files.

[gemini-code-assist]

Code Review

This pull request introduces support for writing backing resource bindings for Functions secret parameters to .env files under the secretEnvParams experiment. The changes include updating resolveBackend and resolveParams to return resolved secret references, adding new fields to SecretParam, and implementing writeResolvedSecretRefs to persist these bindings. The review feedback highlights critical issues regarding case-sensitivity mismatches between camelCase secret names and uppercase .env keys in both applyEnvSecretBindings and writeResolvedSecretRefs, which could lead to deployment failures or duplicate keys. Additionally, the feedback suggests querying the specific pinned secret version instead of hardcoding 'latest' when retrieving secret metadata.

[gemini-code-assist]

Using .filter() here loses the TypeScript type narrowing, meaning secret is still typed as the union Param rather than SecretParam. This will cause a compilation error when attempting to assign secret.resourceId, secret.version, and secret.inLocalEnvironment under strict null/type checks.

Additionally, comparing secret.name === key is case-sensitive. Since .env keys are validated to be uppercase (e.g., APIKEY), but secret parameter names can be camelCase (e.g., apiKey), this comparison will fail to match.

We can resolve both issues and optimize performance by using a simple for...of loop with case-insensitive comparison and type narrowing.

Suggested change

	for (const secret of build.params.filter((param) => param.type === "secret")) {
	if (secret.name === key) {
	secret.resourceId = secretId;
	secret.version = version;
	secret.inLocalEnvironment = true;
	}
	}
	for (const param of build.params) {
	if (param.type === "secret" && param.name.toUpperCase() === key.toUpperCase()) {
	param.resourceId = secretId;
	param.version = version;
	param.inLocalEnvironment = true;
	}
	}

References

1. TypeScript: Never use any or unknown as an escape hatch. Define proper interfaces/types or use type guards. Use strict null checks and handle undefined/null explicitly. ^(link)

[Berlioz]

Is that...true? I mean the case thing definitely is true, fixed.

[wiz-9635d3485b]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	1
Software Management Findings	-
Total	1

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[inlined]

I don't think you mean resourceId to be quoted here

[Berlioz]

sad trombone noises

[inlined]

1. Did we want to default to the existing behavior if the secret doesn't already exist (YOLO secret = key)?
2. I thought we wanted to confirm loop before reusing a secret
3. If reusing a secret we shouldn't needt o create & add a version.

[Berlioz]

e:

1. I don't think so--we talked it over in chat and this would break flows where the user had multiple environments deployed in the same project. Added --force support though.
2. I thought so too but I was working out the logic in my head and right now, if the secret already exists and was created manually or with secrets:set or whatever, we would just pull it in without asking, right? This doesn't actually change the current behavior of secrets?
3. Ack. Recursing like this seems like the most elegant way of handling the input-a-reused-secret case.

[inlined]

Am I reading diffs wrong? It looks like this is set if the experiment is false?

[Berlioz]

Staring at my monitor for a bit and trusting vs code's brace matching, I'm pretty sure this is the fall-through for the big "what's the state of the referenced secret" if block that begins if (!metadata.secret)

[inlined]

is it safe to call writeUserEnvs repeatedly in different places? Does this append? If so, maybe wee should rename it appendUserEnvs

[Berlioz]

It appends yeah. I did want to maintain some sense that this is a filesystem touch when skimming the code though, maybe writeNewUserEnvs()?