GITHUB_ENV does not update when running composite actions multiple times

[GabrielBottari]

Describe the bug
I've separated repeating shell logic to its own composite action. On each run, I'm setting a label into GITHUB_ENV to re-use it down the line. It works the first time, but subsequent calls to the composite action can't seem to update that value, as mentioned in the docs. After trying to set it, it just keeps the old value.

To Reproduce
Steps to reproduce the behavior:

1. Setup a composite action
2. Add step run: echo "label=${{ inputs.label }}-$GITHUB_SHA" >> $GITHUB_ENV
3. Call this action multiple times in your job with different labels

Expected behavior
The environment variable should be updated properly on every call.

Runner Version and Platform

Version of your runner? Where do I see that?

OS of the machine running the runner? ubuntu-latest

What's not working?

There is no output whatsoever

[andreineculau]

I've just stumbled on your issue while having another GITHUB_ENV issue.

A silly idea might be to remove label from GITHUB_ENV first

{grep -v "^label=" > ${GITHUB_ENV}} < ${GITHUB_ENV}
echo "label=${{ inputs.label }}-$GITHUB_SHA" >> $GITHUB_ENV

[vpipkt]

it looks like what happens is the GITHUB_ENV is updated for steps after the composite action runs.

[pragmaticivan]

Has someone found a workaround/ I'm having the same issues in aws-actions/configure-aws-credentials#307.

Currently, copying the assume role block to the root level of the pipeline to fix that. This kinda defeats the purpose of composable actions.

[pragmaticivan]

@andreineculau did your workaround work?

[andreineculau]

@pragmaticivan I didn't have a "production" requirement, I was just playing around and I noticed the behaviour difference that was also mentioned in aws-actions/configure-aws-credentials#307 (comment)

These things require a lot of observations to get right, and behaviour changes over time, so I wanted to understand what is github actually doing here and now. Little did I know that I'll be going at it for hours... 🤦

I cooked up a test with a workflow https://github.com/ysoftwareab/yplatform/blob/debug-github-action-compose-env/.github/workflows/debug.yml calling a composite action :

• two jobs: one with an action reference as github repo and commitish, the other one as local path
• each job has 3 steps
  • an initial call to a composite action that sets new variables
  • a second call to the same action that sets variables, both new ones and old ones (overwriting the ones from initial call)
  • a check that the all variables have been set correctly (outside of the action)

The composite action itself https://github.com/ysoftwareab/yplatform/blob/debug-github-action-compose-env/.github/actions/github-composite-env.yml :

• has 2 inline steps, so bash will set vars by writing to $GITHUB_ENV
• has 2 composite steps, calling an action that will call bash to set vars by writing to $GITHUB_ENV
• has 2 node steps, calling a node action that will run node to set vars by writing to $GITHUB_ENV
• a check that all variables have been set correctly (inside of the action)

Results: "works on my computer" 😝 🤷 You can see a run here https://github.com/ysoftwareab/yplatform/actions/runs/2053929508 . All new vars STEP_X_COMPOSITE_Y are set to true, and the vars that are constantly being overwritten STEP_X_COMPOSITE are also set to the the right index.

One thing to notice, and I really hope I'm not wrong, is that github changed the behavior of $GITHUB_ENV: it is always empty, meaning you cannot read it in order to see which env vars have been set through scripts, and not via the workflow/action's "env" property. Once again, I should really check the git history and look for this change in behaviour, but IF my test were to fail, my initial recommendation in #789 (comment) would not make sense, because there's no env var to remove from $GITHUB_ENV as it is empty at the beginning of the step.

---

Before I pressed Comment to be above, I thought of adding some more variables. And Boom. I got a failure https://github.com/ysoftwareab/yplatform/actions/runs/2054166081

STEP_COMPOSITE and STEP_X don't get overwritten between step 1 and 2. In other words, during the lifecycle of an action, everything is fine and dandy.

My recommendation (remove vars from $GITHUB_ENV before setting them) in #789 (comment) does not hold, because GITHUB_ENV is empty.

The other recommendation (settings vars to empty strings or null via env property) in aws-actions/configure-aws-credentials#307 (comment) does not hold either, because you cannot overwrite them, even if they are "empty" they are still "set". Example https://github.com/ysoftwareab/yplatform/actions/runs/2054230061

The only "workaround" I can think of is to not use $GITHUB_ENV and pass values via outputs maybe, forcing users to manually pass them on to other steps. Don't shoot the messenger 🙏

My wild guess is that somewhere in the code, someone is prioritizing the "first" instance of the variable, instead of the "last".

[pragmaticivan]

I have the same behaviors above in a prod environment 😂 feels like a really important bug to be fixed. Tested all the workarounds above as well and didn't have any change of outcome.

Thanks for sharing your detailed example @andreineculau !!!

[nikola-jokic]

Hi everyone,

This behavior is actually by design. Please refer to this comment. One idea is to specify the outputs of your composite actions and use those outputs to set the outer environment if you need to. Since composite actions are meant to be reusable, it is cleaner to specify outputs as well, that you can use depending on your use case, and not rely on the side-effect by setting the outer env var

[andreineculau]

Hi @nikola-jokic ,

it might be me, but I keep reading the PR comment, and also looking at #1611 that your PR was aiming to fix, and I can't help but think it's another issue and that closing this issue is premature.

For clarity, the #1611 title is now Container actions should prefer the env set in the action.yaml file over set-env,
but it was originally Container actions and composite actions handle environment variables inconsistently.

#1611 is about a difference in environment variable and the priority of set-env/$GITHUB_ENV and env between composite and container actions, while this issue #789 about env variables can be set, but CANNOT BE OVERWRITTEN, by actions for subsequent steps

This issue aligns very well with @thboop's comment

We want to favor what the action author has set, over what the workflow author has decided.

Currently it is not possible to use aws-actions/configure-aws-credentials#307 twice, because the second call will not be able to OVERWRITE existing env vars, therefore going against that comment.

[nikola-jokic]

Hi @andreineculau,

No problem, I am re-opening this issue and I will investigate this further 😊

[pragmaticivan]

Could you open this ticket again until we get more insight? I'm using this on large scale with multiple composite actions to support multiple teams and that seems like a problem for aws-actions/configure-aws-credentials#307

[pragmaticivan]

Anyone could help with reviewing this PR? #1794

[codekitchen]

I just came across this while debugging the same aws-actions/configure-aws-credentials issue -- using that as a step in a composite action doesn't update the AWS_* environment variables for subsequent steps in that composite action. I agree that this is a different issue than updating the env outside the composite action. It is important that env var updates in one composite action step do take effect for subsequent steps in the same composite action.

[metaclips]

Declaring with set-output instead works for me.

[Im2451soon]

네

[Im2451soon]

알았다

[Im2451soon]

한국은 지금 새벽에 가깝다.
낼 연락해도 될까요?

[scott-doyland-burrows]

This shows a really simple example of the issue:

https://github.community/t/gha-github-env-not-behaving-as-expected-with-actions/223170

[bart-lisiecki-form3]

@nikola-jokic Any progress on this? It's quite troublesome and there seems to be no easy workaround.

Env file that GITHUB_ENV points to is still generated per each step in composite action, it's just not "dumped" into env between those steps like it's normally done in a workflow.

It does not seem like it's an intended behaviour, because it works as expected if the env variables are not set (so for example on the first call of the composite action).