-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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 file support #426
Conversation
@torbjornvatn - i really appreciate you working on this! I'm going to need more time to review...lots of changes and it is a bit hard to discern which changes are related to #384 and which were just general "clean up" changes. |
@bixu and I are also running into this issue. I'd be happy to test a release candidate 😃 |
@torbjornvatn - can you fix the conflict? |
@cplee sorry for the delay! |
@cplee I've also fixed the linting issue now. |
Thank you for this very much! I noticed that writing to
|
This PR attempts to add support for the new Environment Files since the
::set-env
command has been deprecated.I found a way to download a tar of the
envs.txt
file that I've assigned to$GITHUB_ENV
from a previous step's container and merge the contents into the env map that is passed to the next step.It's possible that there are more elegant ways of doing this, but I couldn't find any other way of getting access to that file between steps.
UPDATE: I did an new attempt at solving this using the existing command handler, but it didn't work as the new way of setting the envs uses the >> to file syntax. That output can be generated from any command that's called within the
run:
and as far as I understand that can't be intercepted in the command handler.DEPRECATION? We should probably add a warning or an error if you try to use the old and deprecated
::set-env
syntax, but I'm not sure how to best handle that @cpleeFixes #384