Bug: Deployments fail when SECRET_LIST is unset/empty (should be optional)

[rgcottrell]

Deployments fail if no value is provided for the SECRET_LIST secret. Current behavior effectively makes SECRET_LIST mandatory, even though it should be optional.

⸻

Summary

If SECRET_LIST is not set (or is empty), livekit/deploy-action fails during deployment. The only workaround is to set SECRET_LIST to a non-empty value, but that causes unwanted side effects (extra agent secrets created).

⸻

Steps to reproduce
1. Use livekit/deploy-action in a workflow that does not define SECRET_LIST (or defines it as an empty secret).
2. Run the workflow to deploy.

⸻

Expected behavior

Deployment should succeed when SECRET_LIST is not provided. Secret handling should be skipped (or treated as an empty list) when SECRET_LIST is unset/blank.

⸻

Actual behavior

Deployment fails when SECRET_LIST is missing/empty.

⸻

Workaround (undesired)

Set SECRET_LIST to contain at least one KEY=VALUE pair.

Example:
• SECRET_LIST=FOO=bar

This allows the deployment to proceed, but it results in unnecessary creation of agent secrets:
• a secret named LIST
• plus the keys included in the list (e.g. FOO)

That’s noisy and can be misleading for users, especially when they don’t actually need agent secrets at all.

⸻

Proposed fix

Deploy / release the fix from PR #39:

This PR makes SECRET_LIST effectively optional and avoids the failure path when it’s unset/empty.

⸻

Additional notes

This is an easy footgun: users who don’t need secret injection shouldn’t have to define a dummy secret list, and they definitely shouldn’t end up with phantom agent secrets as a side effect.

[HAizelf]

Hit this today on v2.12.1 and dug into the source — root cause below.

Why it fails

The composite action unconditionally injects SECRET_LIST into the container, even when the workflow never defines it (action.yml):

-e SECRET_LIST="${{ env.SECRET_LIST }}" \

So inside the container, SECRET_LIST="" always exists. The env-scanning loop in main.go#L78-L105 picks it up via the SECRET_ prefix, and the guard that's meant to skip it can never fire — os.Environ() entries are NAME=VALUE strings, so the equality check never matches:

if strings.HasPrefix(env, "SECRET_") {
    // ignore the SECRET_LIST env var
    if env == "SECRET_LIST" {   // never true: env is "SECRET_LIST=<value>"
        continue
    }
    secretParts := strings.SplitN(strings.TrimPrefix(env, "SECRET_"), "=", 2)
    // -> secretName = "LIST", secretValue = ""

Every deploy therefore includes AgentSecret{Name: "LIST", Value: ""}. When SECRET_LIST is unset/empty, that empty value is rejected server-side and the whole deploy fails:

{"level":"info","msg":"Loading secret","secret":"LIST"}
{"level":"error","msg":"Failed to deploy agent","error":"twirp error internal: Please enter a value for the secret."}

This same code path explains the noisy extra secrets from the workaround in the issue description: with SECRET_LIST=FOO=bar, you get a secret literally named LIST (value FOO=bar) plus the parsed FOO.

Fix

#39 (open since Nov 2025) implements exactly the needed guard change (strings.HasPrefix(env, "SECRET_LIST=")) — reviewing/merging that would resolve this issue. Beyond the guard, only forwarding SECRET_LIST in action.yml when non-empty would also keep container env clean.

Workaround without junk secrets

Rather than setting a dummy SECRET_LIST, we switched the deploy step to the lk CLI (which sends no secrets unless asked) and kept the action for the status-retry gate, which is unaffected:

- name: Install LiveKit CLI
  run: curl -sSL https://get.livekit.io/cli | bash

- name: Deploy
  env:
    LIVEKIT_URL: ${{ secrets.LIVEKIT_URL }}
    LIVEKIT_API_KEY: ${{ secrets.LIVEKIT_API_KEY }}
    LIVEKIT_API_SECRET: ${{ secrets.LIVEKIT_API_SECRET }}
  run: lk agent deploy --yes .

[real-danm]

Resolved in the latest release