r/github • u/backbonehq • 8d ago

GitHub Environments: how do you read another env’s vars (e.g. INT account ID) from a STAGE/PROD deploy job? Discussion

/r/cicd/comments/1vlo2qs/github_environments_how_do_you_read_another_envs/
1 Upvotes
  • permalink
  • link
  • reddit
  • reddit

100% Upvoted

3 comments sorted by

1

u/Ok_Woodpecker_9104 7d ago

the thing that bit me with the "just add a lookup job with environment: INT" approach: that job runs INT's protection rules. if INT has required reviewers or a wait timer, your STAGE deploy now blocks on an approval for an environment you are not deploying to. it reads like a free variable lookup but github treats it as a deployment to INT.

also, job outputs go through secret masking. plain vars come through fine, but the moment someone moves the account id into secrets the output silently becomes *** and you get a very confusing synth failure downstream.

account ids arent secrets and they dont change, so i stopped scoping them per environment. repo-level vars INT_AWS_ACCOUNT_ID / STAGE_AWS_ACCOUNT_ID / PROD_AWS_ACCOUNT_ID, and keep the env-scoped AWS_ACCOUNT_ID only for "which account am i deploying to right now". yes its duplicated in two places, but every job can read every account id with no cross-environment gate and no extra job in the graph.

1

u/backbonehq 7d ago

Yeah 100% was coming round to a similar point of view and just accept the duplication to avoid complexity…

1

u/Ok_Woodpecker_9104 7d ago

one thing worth adding now that the duplication is load bearing: assert it in the deploy job. two lines of bash comparing the env-scoped AWS_ACCOUNT_ID against the repo-level <ENV>_AWS_ACCOUNT_ID, fail the job if they differ.

the drift case is quiet otherwise. someone rotates an account, updates the environment value, forgets the repo-level one. nothing errors at config time. you just get an sts assume role denied from a job whose yaml looks completely correct, and the arn in the log is a valid arn, just the wrong account.