Inject build parameters into local commands (env run / env shell)

[tiulpin]

Area

Configuration (parameters, projects)

Problem or use case

When developing locally, developers often need access to the same environment variables and parameters that their TeamCity build configurations use. Today, the only way to get these values is to manually copy them from the UI or API, which is tedious and error-prone.

Modern CI/CD CLIs solve this elegantly:

• Railway: railway run npm start injects project env vars into a local command; railway shell opens a subshell with vars loaded
• Vercel: vercel env pull .env.local downloads env vars to a file; vercel env run -- make test injects them without writing to disk

TeamCity has rich parameter support (build parameters, system properties, environment variables) but no CLI path to use them locally.

Proposed solution

Two complementary commands:

teamcity job env <job> -- <command>

Fetches parameters from a build configuration and injects them as environment variables into a local command.

# Run local tests with the same env vars as CI
teamcity job env MyProject_Build -- make test

# Run with a specific branch's parameters
teamcity job env MyProject_Build --branch main -- npm start

teamcity job env <job> --export

Prints parameters in a format suitable for shell eval or .env file:

# Export to .env file
teamcity job env MyProject_Build --export > .env

# Eval into current shell
eval $(teamcity job env MyProject_Build --export --format shell)

Behavior

• Only inject parameters of type env. by default (TeamCity env vars)
• --include-system to also include system. properties
• --include-config to include configuration parameters
• Respect --json for structured output
• Warn (don't error) if a parameter is marked as a password/secret and skip it by default
• --allow-secrets flag to explicitly include secret values (requires confirmation unless --no-input)

Alternatives considered

• Users can script this today with teamcity api + jq, but it's fragile and doesn't handle parameter resolution or secret filtering
• A .env export-only approach (no -- <command> execution) is simpler but less ergonomic — Railway proved that run is the killer feature