-
Notifications
You must be signed in to change notification settings - Fork 958
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
GITHUB_ENV does not update when running composite actions multiple times #789
Comments
I've just stumbled on your issue while having another GITHUB_ENV issue. A silly idea might be to remove {grep -v "^label=" > ${GITHUB_ENV}} < ${GITHUB_ENV}
echo "label=${{ inputs.label }}-$GITHUB_SHA" >> $GITHUB_ENV |
it looks like what happens is the GITHUB_ENV is updated for steps after the composite action runs. |
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. |
@andreineculau did your workaround work? |
@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 :
The composite action itself https://github.com/ysoftwareab/yplatform/blob/debug-github-action-compose-env/.github/actions/github-composite-env.yml :
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
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 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". |
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 !!! |
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 |
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 #1611 is about a difference in environment variable and the priority of This issue aligns very well with @thboop's comment
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. |
Hi @andreineculau, No problem, I am re-opening this issue and I will investigate this further 😊 |
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 |
Anyone could help with reviewing this PR? #1794 |
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 |
Declaring with |
네 |
알았다 |
한국은 지금 새벽에 가깝다. |
This shows a really simple example of the issue: https://github.community/t/gha-github-env-not-behaving-as-expected-with-actions/223170 |
@nikola-jokic Any progress on this? It's quite troublesome and there seems to be no easy workaround. Env file that 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). |
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:
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
The text was updated successfully, but these errors were encountered: