Alternative to secrets for repo-level params?

Currently, my team uses repository secrets to store environment variables that get used across various GitHub workflows to compose environment-specific names. More specifically, we have stage/env names (like “dev” and “prod”) and internal project/app names (let’s used “hermione” as a made-up example) that then get stuck together into an app stage name like “hermione-dev” or “hermione-prod”. We use these values to compose names of infrastructure components like AWS S3 buckets and ECR repos so that we refer to the correct image, bucket, etc. depending on the environment and project. I think it’s not an uncommon pattern, but you may already be seeing the problem with this.

The issue I run into is that secrets cannot be shared between jobs. If I compose a name of an ECR repo in one job, and push to that repo, I cannot output the name of the repo I pushed to and then read that name in a subsequent job that pulls the image. In this case, I need to re-compose the name of the repo in the dependent job. It results in a lot of messy code duplication that is a headache to maintain.

If this were GitLab, I would set these variables as unmasked CI variables, but GitHub has no such feature. What are others doing for repo-wide, non-sensitive environment variables that need to be shareable between jobs?

1 Like

Similar situation. We run some CI tests against Cosmos DB, which we set up with Azure CLI scripting. We try to set up the database in the same region as the GitHub Actions runner for lower latency. But currently, it seems Azure is overprovisioned in eastus2 so you can’t create a Cosmos DB instance there. We wanted a way to inform the CI which Azure regions were OK, without needing to merge PRs to master and multiple support branches (because that would require the CI!) so the only option was a comma-separated list of values stored in a secret.

The information is not secret in the slightest, but secrets can’t be read, only updated, so now we need extensive documentation to show what is the format of the secret, what is the current value anyway, and what values are currently not included?

Repo and org-level Actions configuration values would be a great help for stuff like this.

An option you might consider would be to put the region “whitelist” into a file that’s committed to the repository and then parse the values into the Actions env vars. For example, populate the file azure-region-whitelist with the available regions one per line like so:


Then have a step that parses each line into an env var:

echo "REGION1=$(head -n 1 azure-region-whitelist)" >> $GITHUB_ENV
echo "REGION2=$(head -n 2 azure-region-whitelist)" >> $GITHUB_ENV

For example. I’m sure you could write a short run: script that loops over the file and sets up env vars or a single env var as appropriate.

But I agree, it would be nice if there was also a “parameter store” at the org/repo/environment levels that wasn’t subject to the security measures necessary for secrets.