Using Environment Variables in config.yml not working

envars

#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 }}…


#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

Can I use environment variables in store_artifacts
#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.


#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


#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 ?


#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)


#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

#21

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