nrwl / nx

Smart Monorepos · Fast CI
https://nx.dev
MIT License
23.47k stars 2.34k forks source link

Support environment variables in nx.json #16179

Open jbadeau opened 1 year ago

jbadeau commented 1 year ago

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 commented 1 year ago

There are similar issues that have not been answered of addressed like: https://github.com/nrwl/nx/issues/4606 https://github.com/nrwl/nx/issues/8044 I don't understand why such a basic feature is not supported?

AgentEnder commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 10 months ago

Any update on this issue?

github-actions[bot] commented 2 weeks ago

This issue has been automatically marked as stale because it hasn't had any activity for 6 months. Many things may have changed within this time. The issue may have already been fixed or it may not be relevant anymore. If at this point, this is still an issue, please respond with updated information. It will be closed in 21 days if no further activity occurs. Thanks for being a part of the Nx community! 🙏