Allow to unset env variables

[mpdude]

echo 'SOME_VAR=some-value' >> $GITHUB_ENV can be used to set an environment variable for subsequent steps, but there seems to be no documented way to unset it.

Note that echo 'SOME_VAR=' >> $GITHUB_ENV will set it to the empty value, but that's different from not having the variable set at all.

Rationale: In some workflows, it might be necessary to checkout and/or run untrusted code. At that point I'd like to clean up as much sensitive values as possible. Unsetting env vars (like SSH_AGENT_PID or SSH_AUTH_SOCK) is part of this.

[fhammerl]

Thank you for reporting this issue. Would you mind providing an example workflow to illustrate the issue?

[mpdude]

Sure! It's not a full workflow, but I hope it gets the message across...?

            -   uses: aws-actions/configure-aws-credentials@v1
                with:
                    aws-access-key-id: ${{ secrets.ACCESS_KEY_ID }}
                    aws-secret-access-key: ${{ secrets.SECRET_ACCESS_KEY }}
            -   id: login-ecr
                uses: aws-actions/amazon-ecr-login@v1
            -   run: docker pull some-private/image-from-ECR
            -   run: yarn install

I don't trust yarn install specifically, especially with regard to lifecycle scripts. --ignore-scripts doesn't entirely cut it because sooner or later I will have to run at least some of them (details).

So, basically what I would like to do is to clean up as much as possibly after I've done the parts that I trust more, before I start running the "risky" things.

There is not always an option of splitting such tasks across separate workflows, which would be the best solution obviously.

[mpdude]

Wait… could I just remove lines from $GITHUB_ENV (sed …) and that would do it…?

No. The file seems to be empty at the beginning of each workflow step.

[ethomson]

This seems like a useful addition. I'll put this on the backlog. Thanks for the feedback.

[chrisd8088]

Another use case example for this functionality turned up while working on git-lfs/git-lfs#5236, namely, that the ruby/setup-ruby@v1 action sets the TMPDIR environment variable for subsequent steps, but for the Git LFS project's CI test suite, we need to unset it before running various non-Ruby test scripts. Otherwise, we find that mktemp(1) creates temporary directories under the TMPDIR location but Go language programs using os.TempDir() create them elsewhere, on another volume, and the files cannot then be moved between the two locations.

Resolving this issue while still upgrading to the current ruby/setup-ruby@v1 action from the deprecated actions/setup-ruby@v1 action required us to use env -u TMPDIR in multiple locations. It would be much easier and more robust if we could simply unset a given environment variable by writing once to a GitHub Actions environment file, like the one specified by GITHUB_ENV, as soon as we're done with our Ruby-related actions and want to move on to our Go-related actions.

[Constantin07]

I'm facing the same issue - I need to cleanup AWS creds from the aws-actions/configure-aws-credentials step but don't know how to do it properly.

[michielvermeir]

I'm facing the same issue - I need to cleanup AWS creds from the aws-actions/configure-aws-credentials step but don't know how to do it properly.

Yep, that'd also be my use case. The problem for me is that environment variables exported by aws-actions/configure-aws-credentials always have a higher precedence in the AWS CLI credentials chain than if I were to set AWS_PROFILE.

[AlexAtkinson]

For GITHUB_ENV, you can tear out content with sed. Note specifically that this is simply a file that's sourced, so you can work on it in the same way you might a .bashrc file.

sed -i "/badvar=/d" $GITHUB_ENV

I cut a gist to help explain these convenience files.
https://gist.github.com/AlexAtkinson/f9086c4a88a28cfdce5dbb1b15e947ea

[mpdude]

At least two years ago, that did not work:

#1126 (comment)

[kmcentush]

Has anyone found a workaround? I also was not able to make sed work.