Secrets and environment variables

Question & Answer
1

This question relates to the secrets and env vars tabs. I am trying to avoid using scripts with envman.

First off, why can’t you set secrets for different workflows like you can environment vars? What if I have a different secret key for each environment I need to build for?

Second, starting to play with Secrets and Env Vars and I have a few usage questions which I could not find documented.

  1. Can Secrets reference Env Vars such as:
  • AUTH_ISSUER=$SSO_URL
  1. Can Env Vars reference other Env Vars such as:
  • MY_BUILD_NUM=$BITRISE_BUILD_NUM
  • ENVIRONMENT_NAME=nightly
  • BASE_URL=${ENVIRONMENT_NAME}.company.com
  • API_URL=https://api-${BASE_URL}
  1. Can Env Vars reference Secrets such as:
    (This seems necessary because secrets can’t be split up based on workflow)
  • Secrets:
    NIGHTLY_API_KEY=123
    PROD_API_KEY=456
  • Env Vars:
    Nightly Workflow:
    API_KEY=$NIGHTLY_API_KEY
    Prod Workflow:
    API_KEY=$PROD_API_KEY
1 Like
2

Look here: https://devcenter.bitrise.io/bitrise-cli/most-important-concepts/#availability-order-of-environment-variables

3

ok so

  1. Can Secrets reference Env Vars:

In the value of a Secret Environment Variable, you can use Environment Variables exposed by Bitrise CLI, but you can’t use any other Environment Variable (App Env Vars, Workflow Env Vars, and so on), as those are not processed when Secrets are processed.

  1. Can Env Vars reference other Env Vars:

In the value of an App Env Var , you can use environment variables from Secrets as well as the Bitrise CLI exposed ones, but you can’t use Workflow Env Vars or Step inputs

  1. Can Env Vars reference Secrets:

In a Workflow environment variable you can use all the above ( Secrets , App Env Vars , Bitrise CLI exposed env vars).

These seem to answer my questions, although now new questions arise:

  1. How do you “use” other variables? I didn’t see any syntax examples. Are the following acceptable?
    MY_BUILD_NUM=$BITRISE_BUILD_NUM
    API_URL=“https://api-${BASE_URL}”

  2. I read this:

If the workflow has workflows chained before or after it, the environment variables of the chained workflows are processed and made available right before the first step of the workflow would run.

If I have a generic setup workflow, and then I have environment specific build workflows. Can the setup workflow depend on workflow specific environment variables being set before the setup workflow is ran. This wasn’t entirely clear to me based on the above statement.

1 Like
4

Correct, both should be acceptable.
Keep in mind that variable can only be used in input if its is_expand property is set to true.

Not sure if I understand correctly, but it should be possible. If variable is exported before then it should be available in later stages.

5

Regarding the chained workflows, the setup workflow is using workflow environment variables that are set on the build- workflow it is chained to which is good news.

As far as is_expand, “Replace variables in Inputs”, and “Expose for pull requests”, I guess I don’t really understand those concepts yet.

6

If flag is true then variables in inputs are evaluated by CLI before executing the step eg. $CI will be evaluated to either "true" or "false". OTOH if flag is false then nothing is evaluated and $CI stays "$CI".

If it is disabled then variable won’t exist in PR builds.

7

According to the documentation:

The Expose for Pull Request toggle can be enabled if you want your secrets to be exposed in your build logs in pull requests.

Does this mean they won’t show up in the build logs or they just aren’t available at all?

I’ve been having builds start to fail that are triggered by PRs, and the logs don’t seem to indicate why. I recently started storing auth related values in the secrets.

8

They won’t be available at all.

9

Great thanks for all your help!

1 Like
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.