Global `environment` option to set env variables across all steps

[Andre601]

Clear and concise description of the problem

Right now, there only seems to be a way to define global env variables for the entire CI, rather than a single pipeline itself. In addition is this from what I understand only something an admin can do, meaning users on a shared instance may not have a way to easily define an environment that is accessible across all steps (See "Alternatives" for the ones I know of and their (mostly) cons).

Suggested solution

A global environment option should be implemented, which allows you to define the environment variables you want to use across all steps.

I'm unsure if this global one should be overridable by a step-level environment setting with the same name.

Example:

when:
  - event: push

environment:
  FOO: BAR # Set a global env here.

steps:
  - name: 'echo'
    image: bash
    commands:
      - echo ${FOO}
  - name: 'echo again'
    image: bash
    environment:
      FOO: NOT_BAR # Should this be possible?
    commands:
      - echo ${FOO}

Alternative

From what I understand and gathered are there these possible alternatives, which all have some downsides to them:

• Set a secret.
  • - Using a secret for sharing a non-secret value globally seems wrong.
  • - doesn't allow using other env variables to be processed(? Unsure about this one).
  • + It's available across all steps and can also be used in plugin settings.
• Create a step that saves a value to an envvars file and then later get it.
  • - Depending on the image set may require different commands to set and get.
  • - You can't pull the env in a plugin (unless there is an aproach to run commands before the image execution somehow).
  • - Requires to pull the envvars file on every step to make it available.
  • + Above negative allows only exposing the env to specific steps.

Additional context

No response

Validations

• [X] Checked that the feature isn't part of the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
• [X] Read the docs.
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[stevenroose]

I would like an option like this. I am using a custom docker image with a hash tag and I repeat it many times. I'd like to have a way to have the image description just once and then use image: $TEST_IMAGE in my steps.

[qwerty287]

@stevenroose therefore you should use anchors: https://woodpecker-ci.org/docs/usage/advanced-usage#anchors--aliases

[6543]

I would not add this as this will make all plugins to steps if set ... and using ancors is just fine.

you could efen define a step template as ancor and overwrite things that differ ...

[6543]

If other maintainers are ok with it I'll going to close this as no fix.

As for @Andre601 all building blocks to achive your desired behaviour are already here, if it lacks of documentation, please point me to where we could improve that :)

[Andre601]

I certainly wouldn't even know where in the docs I could look this stuff up to begin with, so that's the first problem there is for this.

Maybe it would be good to work on a cookbook page holding such examples people would use. If that is a thing already should it be presented more prominently.

I still believe global env vars to set is a feature many would benefit from.

[lo48576]

The reason I +1'ed this issue is, environment variable would be easier to concatenate with other strings. Not necessary to be an envvar, but it looks harder (or maybe impossible?) to do it on plain YAML and anchors.

# without envvar
variables:
  rust_image_base: &rust_image_baes: 'rust'
  rust_msrv: '1.81.0'
  rust_msrv_image: &rust_msrv_image 'rust:1.81.0'
  rust_msrv_image_slim: &rust_msrv_image 'rust:1.81.0-slim'

# with envvar:
environment:
  RUST_IMAGE_BASE: rust
  RUST_MSRV: 1.81.0
variables:
  rust_msrv_image: ${RUST_IMAGE_BASE}:${RUST_MSRV}
  rust_msrv_image_slim: ${RUST_IMAGE_BASE}:${RUST_MSRV}-slim

The inability to make the version a variable (RUST_MSRV in the example) is not critical in my case but is frustrating and error prone.

[6543]

ah you want to have them added to the metadata before parsing the whole config ... like done with the CI_* variables ... ... still that should move towards #2254 then ...