This request does not seem to be going anywhere, but is a common item/issue in the forums. One way to resolve many of the issues would be the following

Please can you provide a page per project within the web interface where we can provide the static mapping of named parameters to values in the same way that you do for the more dynamic Trigger Pipeline option that already exists.

As long as you evaluate the provided value as a possible known at runtime environment variable we end up with a solution that correctly allows dynamic external values to be passed to the standard config.yml file at runtime as parameters.

This would address many of the requests/questions posted here in the past and would allow all the issues I have so far come across when using self-hosted runners.

Once such an interface is in place and proven it could also be made visible via the API as all it is, is a simple matrix 3 by n matrix of values.

To an extent you can already do thisecho "export working_dir=\"/go/src/github.com/${ORGNAME}/${REPONAME}\"" >> $BASH_ENVIf you're using bash CircleCI pick this up at each run step. If you want to use it in the current run step you'll need to do source ${BASH_EMV} You can't interpolate variables at execution time eg changing ${ORGNAME} and expect ${working_dir} to be different, but that is a limitation of bash

Some of the scenarios for this are now covered by pipeline variables. See: https://circleci.com/docs/2.0/pipeline-variables/#pipeline-values

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.

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```yamlrestore_cache:

keys:

- assets-v1-{{ .environment.COUNTRY }}-{{ .Branch }}-{{ .Version }} - ...``$COUNTRY`.

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.

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

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

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