Global environmental variables

[siwyd]

Just like vars can be set globally, it would be beneficial to be able to set global environmental variables which would get passed to all tasks.

[smyrman]

Just some input:

If env was possible to specify globally, it should probably also be possible to specify them call time, like you can for variables:

version: "2"
env:
  SOME_VAR: 'value'
tasks:
  default:
    cmds:
    - task: myTask
      env: {"SOME_VAR": "override"}
  myTask:
    cmds:
    - echo $SOME_VAR

SOME_VAR=override

Personally however, I prefer setting the environment through an explicit step per task:

version: "2"
vars:
  SOME_VAR: 'value'
tasks:
 default:
    cmds:
    - task: myTask
      vars: {"SOME_VAR": "override"}
  myTask:
    env:
      SOME_VAR: '{{.SOME_VAR}}'
    cmds:
    - echo SOME_VAR=$SOME_VAR

SOME_VAR=override

From experience it makes it easier when/if a variable name need to be replaced, and the environment of any given task would never get polluted (by anything set in the task file - you could of course set and export values in your terminal).

[andreynering]

Hi @siwyd,

Indeed, this feature was thought in the past, but forgotten

Thanks for opening an issue for it

[siwyd]

@smyrman Agreed, you need a logical way of overriding 'default' environmental variables down to the task and command level, just like with vars now.

My use case is the following:

version: '2'

vars:
  UID:
    sh: echo "$(id -u $USER)"
  GID:
    sh: echo "$(id -u $USER)"

tasks:
  tls:
    cmds:
      - mkcert -install
      - mkdir -p tls
      - cd tls && mkcert example.localhost'

  up:
    cmds:
      - docker-compose up -d --build
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  build:
    deps: [up]
    cmds:
      - docker-compose exec java ./gradlew build
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  shell:
    deps: [up]
    cmds:
      - docker-compose exec java bash
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  run:
    deps: [tls, build]
    cmds:
      - cmd: docker-compose execjava ./gradlew bootRun -x test
        ignore_error: true
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  test:
    cmds:
      - docker-compose exec java ./gradlew test
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  stop:
    cmds:
      - docker-compose stop
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  down:
    cmds:
      - docker-compose down -v
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  fe:
    cmds:
      - docker-compose exec java npm install
      - cmd: docker-compose exec java gulp
        ignore_error: true
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  redis-failover:
    cmds:
      - docker-compose pause redis1
      - docker-compose exec redis2 redis-cli SLAVEOF NO ONE
      - docker-compose unpause redis1
      - docker-compose exec redis1 redis-cli SLAVEOF redis2 6379
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

As you can see, that's a lot of repeating. I need those environmental variables for every docker-compose command, as they get passed to the Docker build context.

@andreynering Thx so much for go-task, I like it very much :)

[andreynering]

Thx so much for go-task, I like it very much :)

Thanks for the words! 😄

BTW, this is probably not hard to implement, in case anyone want to try, until I have the time to do it myself.

[tonobo]

I've the same issue but out of scope. I want to share whole tasks just overriding a few details. How about adding a kind of inherit mechanism.

version: '2'

vars:
  UID:
    sh: echo "$(id -u $USER)"
  GID:
    sh: echo "$(id -u $USER)"

tasks:
  tls:
    cmds:
      - mkcert -install
      - mkdir -p tls
      - cd tls && mkcert example.localhost'

  base:env:
    env:
      UID: "{{.UID}}"
      GID: "{{.GID}}"

  up:
    inherit: [ "base:env" ]
    cmds:
      - docker-compose up -d --build

  build:
    deps: [up]
    inherit: [ "base:env" ]
    cmds:
      - docker-compose exec java ./gradlew build
...

[andreynering]

@tonobo I think we should do the easy first, i.e. have global environment variables.

But mixings are indeed an idea for those that have many tasks.

I saw @zbindenren using YAML to do that. I don't think I'd recommend that, though.

[tonobo]

Using anchors isn't an option for me, i need to include files from remotes and share the settings with those tasks. I already started writing a proposal. :smile:

[andreynering]

Global environment variables are now implemented on #159.

See: https://taskfile.dev/usage/#environment-variables

[Firesphere]

I get this error when following your link @andreynering

Websites prove their identity via certificates. Firefox Developer Edition does not trust this site because it uses a certificate that is not valid for taskfile.org. The certificate is only valid for the following names: artofkapitzke.com, m.artofkapitzke.com, www.artofkapitzke.com

[pd93]

I get this error when following your link @andreynering

@Firesphere Task moved to the taskfile.dev domain quite a while ago and this obviously never got updated. Thanks for spotting. There are probably other ancient references to the old domain too, but it's fairly impractical to find and update all of these.

@andreynering I've taken the liberty of updating the link in your comment.