[metalwarrior665]

Tests should run an Actor with the same env vars users run it with. This adds a check that the version being built has env vars with the same names as the Actor's default version. Only names are compared, because the API doesn't return secret values.

Changes

• CLI: build and build-from-local take --require-env-vars-in-sync, off by default so one-off builds (e.g. of a debug branch) aren't held up. When set, the build fails if a name is missing or extra, e.g. Env vars of version 0.99 are out of sync with default version 0.1 (missing A; extra C). A dry run checks it too.
  • build compares whatever --version-number resolves to; build-from-local compares 0.98.
  • A version that doesn't exist yet counts as having no env vars, and the error then says to create it on the platform first.
• Workflow: public_pr-build-test.yaml gets a require-env-vars-in-sync input that defaults to true and passes the flag to build. Repos opt out with:

  with:
      require-env-vars-in-sync: false

• Docs: new "Env var check" section and flag rows in docs/cli.md, input row in docs/workflows.md. CLI bundle rebuilt.

Breaking

Once workflows-v0 moves, PR builds fail in repos whose 0.99 version has different env var names than the default version. They need to align the env vars on the platform or set the input to false. This stays on workflows-v0 since we're before v1.

Testing

• Unit tests for the check (matching names in any order, missing/extra names, missing test version, missing default version), and for build and build-from-local with and without the flag.
• npm test, tsc, eslint and prettier pass. Checked that yargs parses --require-env-vars-in-sync=true/=false as booleans, and ran the bundled CLI with the flag.
• Not yet run in GitHub Actions against a real Actor.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uf4mMpBhZCNatL6cLh2Ywt

[JuanGalilea]

good initial step on having proper env stuff.

don't like it as a long term thing, but this will protect us from dumb mistakes nonetheless

[metalwarrior665]

don't like it as a long term thing

I think this could stay as a simple default base level protection. While the env from GitHub would be for devs who want to automate and customize more.

[ruocco-l]

I don't particularly like the fact that we are forcing users to interact with console to add manually a secret to have a correct sync every time they want to add a new secret, but as of now we still have to do it and this just adds the check, so all good 👍

[metalwarrior665]

Will merge in 2-3 days to give devs time to read the Slack post