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
Allow suppressing warning when overwriting env variable #326
Comments
Hi there @anuraaga 👋! Thank you for opening an issue. Our team will triage this as soon as we can. Please take a moment to review the troubleshooting steps which lists common error messages and their resolution steps. |
Hi @anuraaga - the warning is just that, a warning. If you know what you're doing and it's intentional, you can ignore the warning. |
CIs are a shared system, even if the author of a workflow may understand the nature of a warning, other members looking at the workflow result will be confused by warnings being raised. Having a clean build without warnings is important for maintaining shared systems I think. Isn't it a bit hasty to just close the issue without considering the UX? |
Thanks for the context @sethvargo. Also for anyone else that may find this issue, I noticed that the check for the warning is truthiness, so while it doesn't seem possible to remove already set env vars in a github action, setting to empty string worked fine to suppress the warnings. This sort of step can do it
|
TL;DR
Currently, a warning is always emitted when overwriting an env var. This will happen easily when using the action twice in the same workflow.
https://github.com/google-github-actions/auth/blob/main/src/main.ts#L302
There are workflows where this makes sense though, for example when running e2e tests against one project and then pushing an image to another. It would be nice if there was an option to suppress this warning where it is expected behavior. Alternatively, removing the warning would fix the problem too - I noticed it was added in #157 which was about flagging out variable export, but I don't see any mention of a user request or motivation for the warning. Does't mean it shouldn't be there, just trying to link for the history - I think it's worth considering leaving out an additional option and only logging a warning in ACTIONS_STEP_DEBUG mode.
Detailed design
or perhaps a polymorphic type for the current one
When
overwrite
, it is the same astrue
but suppresses the warning.or check
ACTIONS_STEP_DEBUG
and log the warning when true without any additional option.Additional information
No response
The text was updated successfully, but these errors were encountered: