CircleCI Ideas

Allow env var interpolation

Users desire to use environment variable expansions in few places, namely `working_directory` and in the environment section.

Currently, we treat all values as literals and no interpolation is supported.

Frequent patters for desiring the feature is:

  • in `working_directory`, e.g. `/go/src/$ORGNAME/$REPONAME`
  • Related to paths, e.g. `PATH=/go/bin:$PATH`, `VERSION=0.0.$ {CIRCLE_BUILD_NUM}


  • Advanced uses, e.g. `TOKEN=$(heroku auth:token)`

For working_directory, the workaround is nuisance but is somewhat reasonable.

For the environment case, the workaround currently is for users to use an export in the command rather than the environment variable section - which is just annoying...

- run:
    command: |
      export PATH=/go/bin:$PATH
      go-vet ....

# instead of
- run:
    command: go-vet ...

1.0 uses the `export` syntax for setting environment variables. This may be sufficient in 2.0 - but it is a bit verbose.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Nov 23 2017
  • Taking votes
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    5 Dec, 2019 11:00pm

    Some of the scenarios for this are now covered by pipeline variables.  See:

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    22 Mar, 2019 03:13pm

    There hast to be a way to write to circle variables, parameters, etc without changing the config.yml 

    This is an implementation idea that would be super convenient, but I think it's valuable to point out the underlying need and that it's still applicable. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    4 Jun, 2018 12:11pm

    Would this also apply to cache keys? e.g., we extensively use YAML references to deduplicate build steps that check asset generation in every locale, so it'd be great to be able to put


        - assets-v1-{{ .environment.COUNTRY }}-{{ .Branch }}-{{ .Version }}
        - ...
    in a reference, and then be able to run that job multiple times for different values of `$COUNTRY`.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    10 Apr, 2018 07:37pm

    This issue is on our radar -- we are likely to introduce first-class parameters to jobs along with reusable commands that would make it easier to make values like cache paths, working directory, images, and others dynamic. We are, though, hesitant to do this with env vars, as our general approach is to make env var injection as "late" in the process as possible and only in a runtime environment you have specified. Config processing is done before your code is executed and before the runtime environment you specify in your executor is provisioned, and we do not generally want to be accessing your env vars at that stage. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    10 Apr, 2018 06:29pm

    -1 from me - I think making interpolation in YAML makes each step, or certain steps, or the file, or certain attributes on steps, or any other location it can be used confusing. Adding more interpolation features and special processing of the YAML static data will make it more difficult write, debug, and comprehend. I think a much better idea is which would allow for users to do this themselves in their own complex world without making this the common case for all users. Adding even more special processing to YAML can end up like GitLab's absolutely bonkers include directive (

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    12 Mar, 2018 08:48pm

    env interpolation needs to be supported throughout config.yml, not just in specific sections.  it's essential for numerous workflow use cases.  

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    6 Mar, 2018 10:57pm

    I have set up an open-source solution I call WP DevOps specifically for managing WordPress sites although it is not yet v1.0 and as such does not yet have an example circle.yml file.

    Given WP DevOps architecture it would be utterly impossible to move it to 2.0 without environment var interpolation

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 Feb, 2018 03:47pm

    Environment interpolation is a long requested feature:

    @Alexey: What is the workaround for the `working_directory`?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    5 Feb, 2018 06:18am

    (I tried creating a fixed symlink at /tmp/node_modules pointing to the dynamic directory, but it unfortunately caches the symlink, so the contents of the directory it points to.)


    Likewise in the checksum of the cache key. Current workaround is to cat the contents of a dynamic file to a static `.lock` file. This appears to work, but the solution as a whole doesn't work because I can't save a dynamic path.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    5 Feb, 2018 06:06am

    I would particularly like to be able to interpolate in `save_cache: paths`, so I can generalise my build steps and interpolate the service name.