Support environment variables in nx.json

[jbadeau]

• I'd be willing to implement this feature (contributing guide)

Description

I think supporting interpolating environment variables in at least the nx.json would be extremely welcome as it would dramatically simply pipelines.

Motivation

Tasks need to be able to read values from the env such as gitlab/github ci variables. Tasks could write envvars directly to the host or via .env files and subsequent tasks could pass them as options. Currently every plugin developer or user needs to create workarounds like postTarget from semvers to pass values from one task to another. All of your competitors support this and it makes the NX very verbose because of workarounds to get access to envvars.

Suggested Implementation

{env.SOME_VALUE} would interpolate envvar SOME_VALUE.

    "build-chart": {
      "executor": "@techx/nx-helm:build",
      "options": {
        "chartPath": "chart",
        "destination": ".",
        "repository": "techx",
        "version": "{env.VERSION}"
      }
    }

Alternative Implementation

{$SOME_VALUE} would interpolate envvar SOME_VALUE.

    "build-chart": {
      "executor": "@techx/nx-helm:build",
      "options": {
        "chartPath": "chart",
        "destination": ".",
        "repository": "techx",
        "version": "{$VERSION}"
      }
    }

[jbadeau]

There are similar issues that have not been answered of addressed like: #4606
#8044
I don't understand why such a basic feature is not supported?

[AgentEnder]

Hey @jbadeau! This is something we are considering supporting for target options in general, rather than just in nx.json. There are some complexities as allowing substitution in these makes migrating them much harder.

Imagine a migration that renames the project's jest configuration file. If the path to that file contains an env variable, or {projectRoot}, its another step that can be forgotten and makes our migrations a bit more fragile.

This is the reason that its not currently supported, and also the reason that we don't support things like {workspaceRoot}, {projectRoot} etc inside project.json but rather limit them to nx.json

We will continue to evaluate the support, its not something that we've ruled out but something that needs to be considered.

[jbadeau]

Now that v16 is loose is there any chance to have a look at this?

As a first step, why not enable envvars for target options first. This is the main place where they are required.

"release-gitlab": {
  "executor": "@techx/helm:install",
  "options": {
    "chart": "nginx",
    "version": "${CHART_VERSION}",
    "release": "nginix"
  }
}

This would allow for many of the benefits but would not impact migration.

[AgentEnder]

This is something we are still evaluating the effects of, and determining the proper syntax and design for implementation. We don't want to break existing executors that may expect similar tokens to be present, as an example.

Some of the core team is on vacation, once everyone is back I'll raise it and see what people's thoughts and concerns are, and then we can give it the green flag. Something like this isn't out of the question, just need to go about it the correct way.

[jbadeau]

Any update on this issue?