Submit Your Ideas

We want to hear from you - vote for the features and improvements you'd most like to see, or submit your own ideas if you don't find them already listed.

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/github.com/$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 ...
    environment:
      PATH=/go/bin:$PATH

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
  • Future consideration
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    February 5, 2018 06:06

    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.

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

    (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
    February 14, 2018 15:47

    Environment interpolation is a long requested feature: https://discuss.circleci.com/t/reference-an-environment-variable-in-environment-yaml-map/10792

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    March 6, 2018 22:57

    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
    March 12, 2018 20:48

    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
    April 10, 2018 18:29

    -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 https://circleci.com/ideas/?idea=CCI-I-184 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 (https://docs.gitlab.com/ee/ci/yaml/#include

  • Admin
    Nathan Dintenfass commented
    April 10, 2018 19:37

    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
    June 4, 2018 12:11

    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
    ```yaml
    restore_cache:

      keys:

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