env limitation

[igor-ivanov]

It seems that env is processed after matrix
As a result following yaml does not work as expected

matrix:
  axes:
    flags:
      - default
      - extra
    arch:
      - x86_64

env:
   TARGET: ${flags}

steps:
...

so workaround is required as:

matrix:
  axes:
    flags:
      - default
      - extra
    arch:
      - x86_64

steps:
  -name: N1
    run: export TARGET=${flags}
...

[mike-dubman]

• matrix is dynamically generated
• env is statically set once

current matrix dimension is passed to step as env variables and can be referred as $flags inside step
why need to refer matrix var from env section?

[igor-ivanov]

why need to refer matrix var from env section?
Just to avoid doing identical operations as

steps:
  -name: N1
    run: export TARGET=${flags}
  -name: N2
    run: export TARGET=${flags}
...
  -name: NN
    run: export TARGET=${flags}

Every step get a list of environment variables from env. Probably it is more flexible to get environment variables with different values.

[mike-dubman]

but both env and matrix var available inside step shell
from shell step you can refer $flags and also vars from env
cross reference matrix and env in yaml file seems obscure because they resolved at runtime
WDYT

[igor-ivanov]

but both env and matrix var available inside step shell

it is true

from shell step you can refer $flags and also vars from env

it is true

cross reference matrix and env in yaml file seems obscure because they resolved at runtime
WDYT

currently I must do #23 (comment) instead

env:
   TARGET: ${flags}

steps:
  -name: N1
  -name: N2
...
  -name: NN

I can live with current solution if my proposal meets initial arch design

[mike-dubman]

IMO approach in #23 (comment) is clean and nice
dereferencing matrix var in env makes it complicated
let me know if you disagree or close