Using Environment Variables in config.yml not working

Feedback & Bug Reports
1

I’m using CircleCI 2 and this is my config.yml file:

version: 2
jobs:
    build:
        machine: true
        working_directory: ~/komed-health-web
        environment:
            BS_PROJECT: "Komed Health on CircleCI"
            BS_BUILD: "Build No. $CIRCLE_BUILD_NUM for CircleCI"

In my project the env variable BS_BUILD is now “Build No. CIRCLE_BUILD_NUM for CircleCI” (notice without the ). Am I doing something wrong? It also didn't work with "{CIRCLE_BUILD_NUM}" or {{ .Environment.CIRCLE_BUILD_NUM }}…

5 Likes
2

Have you tried specifying them in the machine/environment section instead of jobs/build/environment?

We do this here, and it seems to work.

3

Thanks for the answer. I see the repo you posted is version 1.0. My configuration is circle ci v 2.0

I don’t think you can define the environment in machine. It’s fixed in jobs/build/environment, I think…

4

Ah, indeed - I didn’t even think about this! Good we didn’t switch to 2.0 then.

6

There is no first class support for this anymore in 2.0

You can read about this and other changes here: https://circleci.com/docs/2.0/migrating-from-1-2/#search-and-replace-deprecated-20-keys

The following command should work as a workaround.

run: echo 'export BS_BUILD="Build No. $CIRCLE_BUILD_NUM for CircleCI"' >> $BASH_ENV
7

@levlaz Why was this functionality removed? I have this:

environment:
  - API_URL: http://api.example.com
steps:
  - run:
      name: Deploy ${CIRCLE_PROJECT_REPONAME} to ${API_URL}
      command: make all

That doesn’t work either, and I’m not sure the workaround above can be applied in any reasonable way to make it work. If I have to hardcode everything, I guess I will.

8

Thanks @levlaz for the reply. Do you know if or when this feature will be supported again?

9

It’s on our roadmap to support env var interpolation on 2.0. I don’t have an ETA right now.

1 Like
10

Circling back to Can I use environment variables in store_artifacts - environment variables used to work for store_artifacts, so please do add support for them in 2.0.

11

Any idea if future environment variable interpolation support will apply throughout the config.yml? I’d really like to be able to use them when mapping environment: and other settings when specifying additional docker images, for example:

version: 2
jobs:
  build:
    docker:
      - image: circleci/golang:1.9
      - image: hashicorp/http-echo
        command: [-text, $TEST_MESSAGE]
    steps:
      - run: curl -v http://localhost:5678/

In this example, it would be great if TEST_MESSAGE could come from the project environment settings since right now it just outputs $TEST_MESSAGE verbatim.

[EDIT] Note: I logged this as a feature request since I wasn’t sure if there was a feature request tracking improved environment variable interpolation support in CircleCI version 2:
Environment variable interpolation throughout .circleci/config.yml

3 Likes
12

For the work around you provided do I have to add that run command to a certain section of the configuration yaml file? I’ve not seen a run section / command nor can I find it in the docs. I am trying to get the build number for a sed command that runs in our test -> post section of the build. Any help you can provide in getting a work around would be great.

13

Interesting. Why then you left that in docs for v2.0:
https://circleci.com/docs/2.0/env-vars/#adding-environment-variables-to-a-job ?

1 Like
14

This is separate. Adding environment variables as strings works.

The issue is doing string interpolation when setting environment variables. (i.e. using one envvar to set another envvar)

1 Like
15

please fix this! not being able to interpolate variables in store_artifacts blocks - among other places - is extremely frustrating.

16

Hello,
When can we expect store_artifacts to support environment variable interpolations?
Thank you!!

17

Can you show a use case for this? Maybe there is a work-around. Without more detail it is hard to say if this would work, but look into a hardwired path for your artifact command, and then the creation of a symlink to that path in a prior step. This symlink creation can incorporate env vars.

You’d have to test this to see if Circle’s artifact system can read symlinks correctly, but it’s worth a try.

18

Hi !
I have a workflow, and all of the jobs will be running several testsuites.
I want to store artifacts for each testsuite run. I am hoping I can do something like this:

  - run: *run_abc_test
  - store_artifacts:
      path: $WORKDIR/$BRANCH_$LABEL/abc_test/tests_html
      destination: abc_tests_html

and WORKDIR, BRANCH and LABEL are environment variables set at the beginning of the job in my .circleci/config.yml file.

19

Right, I think my idea would work. Create a new run step before your store step, and in that, create a symlink from $WORKDIR/$BRANCH_$LABEL/abc_test/tests_html to /tmp/tests_html, and then you can use the hardwired path in your store step. Let me know how you get on.

20

Thank you so much!! It works.

I defined:
  - &prep_artifacts
    name: prep_artifacts
    command: |
      mkdir /tmp/abc_tests_html
      cp $WORKDIR/$BRANCH-$LABEL/abc/tests_html/* /tmp/abc_tests_html

In my job, I do:
      - run: *prep_artifacts
      - store_artifacts:
          path: /tmp/abc_tests_html
          destination: abc_tests_html
1 Like
21

Great! Would you apply code formatting to those snippets, so they are more readable?