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 passing of context or other shared env vars into secondary docker images in a job

Presently the only available use for context/project level env configs is within command line arguments and bash scripts. However, there are areas where environment vars would be useful being interpolated into other configuration sections of the yaml file. Such as declaring environment configuration for requested images in the initial docker block of the config file. It would be great to be able to take advantage of contexts beyond just bash scripts and command blocks.

 

Currently in order to configure services in a custom manner you must use a series of docker run commands. This also forces you to run any tests/integration steps inside an additional container to talk to those services (for us this adds 30s - 1m of building a new docker image and spinning it up which contains the new code on each commit which should be an unnecessary step).

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jun 25 2018
  • Future consideration
  • Attach files
  • Admin
    Nathan Dintenfass commented
    June 25, 2018 20:39

    We are working on a way to use parameters in config, though our current plan is to not allow straight environment variable interpolation outside of your runtime to avoid leaking secrets. Today, Contexts work by requesting them as part of a job invocation, which happens at runtime after we've processed the configuration, so there isn't a clean way to use context variables outside the running build. Can you elaborate on the scenario you described and why using env vars inside the build aren't working? Is it specifically about getting those variables into your secondary containers (the ones listed under your primary, where your steps are executed)?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 25, 2018 21:00

    Nathan, it is specifically about getting configuration into the secondary containers. We do not want individual engineers being able to simply set these variables to whatever they want nor do we want to have to manage variables across multiple projects when they are the same for each of them.

    One such case is we have two services, one dependent on the other. The first is an Email service, which depends on our second service Auth. Ideally we could use the secondary image block to pull in a running instance of Auth for our Email service tests. However, because we cannot pass configuration through from the context we are forced to hard-code it.

    This doesn't work for us, as any service that requires Auth will now have hard coded values (n duplicates). As a result, we are forced to use docker commands to run any dependencies as well as build a container to run the tests in the same network.

  • Admin
    Nathan Dintenfass commented
    June 25, 2018 22:01

    That makes sense - can't make any promises given our current backlog, but I'm moving this into our set of cards for further discussion... 

  • Admin
    Nathan Dintenfass commented
    June 25, 2018 22:03

    I'm also taking the liberty of updating the name of this idea to more narrowly target the scenario you need.