Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow environment variables for tags #770

Open
GuilleAmutio opened this issue Apr 5, 2023 · 7 comments
Open

Allow environment variables for tags #770

GuilleAmutio opened this issue Apr 5, 2023 · 7 comments

Comments

@GuilleAmutio
Copy link

I would really like to have the option of defining the TAGs for the images as environment variables. Maybe this is already possible but I could not find the right way to do it.

On my targets field on the project.json I have:

"docker":{
      "executor": "@nx-tools/nx-container:build",
      "options": {
        "tags": [ "executor"],
        "context": "apps/my-project-frontend",
        "dockerfile": "Dockerfile",
        "engine": "podman",
        "load": true,
        "buildArgs": {
          "TAG": "$BASE$(date +'%Y%m%d%H%M%S')"
        }
      },
      "configurations": {
        "development": {
          "buildArgs": {
            "BASE": "myproject.frontend.dev."
          }
        }
      }
    }

So the tag would be something like my myproject.frontend.dev.20230404122321 (I know it is not the best way to TAG, but let's say it is a requirement).

Is this already possible?

@gperdomor
Copy link
Owner

@GuilleAmutio you want the tag be myproject.frontend.dev.20230404122321 or only 20230404122321??? in any case you can do something like this... Let's say that you have this target:

   "docker": {
      "executor": "@nx-tools/nx-container:build",
      "options": {
        "engine": "docker",
        "tags": ["myproject.frontend.dev"],
        "load": true
      }
    }

You will get myproject.frontend.dev:latest as tag which should be enough for a local or dev environment, but if you want to customize that in a CI environment you can use INPUT_TAGS env variable...

For example:
INPUT_TAGS=myproject.frontend.dev:$(date +'%Y%m%d%H%M%S') nx run your-app:docker

And with that you will get something like myproject.frontend.dev:20230418232045

@nsainaney
Copy link

Unfortunately, setting INPUT_TAGS=foo completely overwrites:

"tags": [
    "type=schedule",
    "type=ref,event=branch",
    "type=ref,event=tag",
    "type=ref,event=pr",
    "type=sha,prefix="
]

it would be nice to support arbitrary environment variables using the type=raw option which is part of the metadata spec: https://github.com/docker/metadata-action#typeraw

So

"tags": [
    "type=schedule",
    "type=ref,event=branch",
    "type=ref,event=tag",
    "type=ref,event=pr",
    "type=sha,prefix=",
    "type=raw,foo",
    "type=raw,$FOO"
]

would allow for env variables as well as arbitrary values.

@tafaust
Copy link

tafaust commented Nov 19, 2023

I still don't understand the what takes precedence between nx.json and an apps project.json. It'd be nice if the options are merged in order. That could potentially solve the env var problem with something like

INPUT_TAGS=type=raw,$(date +'%Y%m%d%H%M%S')

?

(A single metadata.images in my project.json seems to overwrite the whole metadata object in nx.json. Not sure if that is the intended behavior because it results in a lot of copy and paste.)

@mpauly-exnaton
Copy link

We just ran into a similar problem as @nsainaney: we'd like certain tags to be enabled only on a release, so something akin to

"type=raw,value={{branch}}-{{date 'YYYY-MM-DD.HHmmss'}}-{{sha}}",
"type=semver,pattern={{version}},enable=${{ github.event_name == 'release'}}",

However, ${{ github.event_name == 'release'}} is not available inside nx-container.
To deal with such cases, it would be really useful to have access to (parts of) process.env inside the tags.

As far as I can tell that should be possible by adding an additional key to the render context of the handlebar call here. Probably only envvars starting with a particular prefix such as INPUT_EXTRA_ARGS_ should be picked up. @gperdomor does that sound like a reasonable solution to you? Would you be willing to accept a PR for that?

@ThorstenKunz
Copy link

If it is too cumbersome to allow ENV variables as part of the config tags definition maybe it would be easier to add an additional input like e.g. "INPUT_ADDL_TAGS" that doesn't replace the tags created through the "tags" config but just adds them as additional tags?

@gperdomor
Copy link
Owner

Hello everyone, first of all sorry for the delay in responding, I have been very busy lately... I just want to comment that several parts of the plugin flow have support for environment variables interpolation, so this works fine:

"docker": {
  "executor": "@nx-tools/nx-container:build",
  "options": {
    "push": true,
    "tags": [
      "ghcr.io/your-org/api:$DATE",
      "ghcr.io/your-org/api:$COMMIT_HASH"
    ],
  }
}

Also, for automatic metadata tagging, RAW tags are also supported doing something like this:

"container": {
  "executor": "@nx-tools/nx-container:build",
  "dependsOn": ["build"],
  "options": {
    "engine": "docker",
    "metadata": {
      "images": ["user/sandbox"],
      "tags": [
        "type=schedule",
        "type=ref,event=branch",
        "type=ref,event=tag",
        "type=ref,event=pr",
        "type=semver,pattern={{version}}",
        "type=semver,pattern={{major}}.{{minor}}",
        "type=semver,pattern={{major}}",
        "type=sha,prefix=sha-",
        "type=raw,value=foo-$DATE",
        "type=raw,enable=$RAW_ENABLED,priority=200,prefix=$PREFIX,suffix=$SUFFIX,value=bar-$DATE"
      ]
    },
    "load": true
  }
}

In both cases you need to setup the environment variables in your terminal or CI provider.

If you need more information please share your config and we can work together to find a way to solve your issue :D

@w8ze-devel
Copy link

Hello @gperdomor

Thanks for the sample of using RAW tags.

I coudn't find in the documentation rules about which tag will be used.

In your exemple, when will the semver used ? And does the major and minor comes from package.json ?

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants