Skip to content

Conversation

@sethvargo
Copy link
Contributor

Reverts #148

As I kinda suspected but couldn't remember, there's a reason we use the action's temporary directory.

/cc @travisgroth @ViacheslavKudinov

@sethvargo sethvargo requested a review from bharathkkb July 22, 2020 11:58
@travisgroth
Copy link

Is there no other place these can be kept? Does HOME get mounted in docker steps? https://docs.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#filesystems-on-github-hosted-runners

It'd be nice if there was a full reference on the different env vars and how they work out in VM vs Container.

@ViacheslavKudinov
Copy link

ViacheslavKudinov commented Jul 22, 2020

Is there no other place these can be kept? Does HOME get mounted in docker steps? https://docs.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#filesystems-on-github-hosted-runners

It'd be nice if there was a full reference on the different env vars and how they work out in VM vs Container.

It's how looks default run of Docker based GH action for our case:
/usr/bin/docker run --name c20191433d3ea2a95661c0f83a8e9e741a17_42b255 --label 87c201 --workdir /github/workspace --rm -e GOOGLE_CREDENTIALS -e TF_VAR_sealed_secrets_master_key -e TF_VAR_sealed_secrets_master_key_crt -e TF_VAR_crypter_decrypter_service_account_key -e TF_WORKING_DIR -e TF_ACTIONS_VERSION -e TF_WORKSPACE -e CLOUDSDK_METRICS_ENVIRONMENT -e GOOGLE_APPLICATION_CREDENTIALS -e INPUT_TF_ACTIONS_VERSION -e INPUT_TF_ACTIONS_SUBCOMMAND -e INPUT_TF_ACTIONS_WORKING_DIR -e INPUT_TF_ACTIONS_CLI_CREDENTIALS_HOSTNAME -e INPUT_TF_ACTIONS_CLI_CREDENTIALS_TOKEN -e INPUT_TF_ACTIONS_COMMENT -e INPUT_TF_ACTIONS_FMT_WRITE -e INPUT_TF_ACTIONS_GCLOUD_SA_KEY -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/dpe-iac/dpe-iac":"/github/workspace" 87c201:91433d3ea2a95661c0f83a8e9e741a17
in theory we can use option section of workflow file to fix our case and define mount of volumes like in this example https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-15.

Maybe, the way to use one more input param for this action and to set either RUNNER_TEMP or GITHUB_WORKSPACE as a "workspace" also will be fine.

@sethvargo
Copy link
Contributor Author

in theory we can use option section of workflow file to fix our case and define mount of volumes like in this example https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-15.

Sure, but that's a breaking change. I think we should revert this. If we want to introduce that change, it should be in a new tagged version so people can upgrade safely.

Copy link
Contributor

@bharathkkb bharathkkb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
Seems like macos tests are queued/failing but I dont think its related.

@sethvargo sethvargo merged commit 0926395 into master Jul 22, 2020
@sethvargo sethvargo deleted the revert-148-sethvargo/export_path branch July 22, 2020 21:43
@github-actions github-actions bot mentioned this pull request Oct 12, 2020
sethvargo added a commit to google-github-actions/auth that referenced this pull request Jul 10, 2025
The GitHub Action currently puts generated credentials into $GITHUB_WORKSPACE (/github/workspace). Unfortunately this is also the working directory of the checkout, so it's too easy to accidentally bundle the generated credentials into Docker containers, binaries, or anything that uses `*` or `.` as a build context.

In the past, we tried to move the exported credentials into RUNNER_TEMP or other directories, but it always introduced incompatibility with the various community workflows (Docker, self-hosted, etc.):

- google-github-actions/setup-gcloud#148
- google-github-actions/setup-gcloud#149
- google-github-actions/setup-gcloud#405
- google-github-actions/setup-gcloud#412

While undocumented, it appears that `/github/home` is an understood path, AND that path is mounted into Docker containers. That means we can export credentials outside of the workspace and still have them available inside the Docker container without users taking manual actions. This comes at three major costs:

1. We have to write the file into two locations. This isn't ideal, but it's also not the end of the world.

2. We would be relying on an undocumented filepath which GitHub could change at any point in the future. Since this is not part of the publicly-documented API, GitHub is within their rights to change this without notice, potentially breaking everyone/everything.

3. Because of the previous point, there are no environment variables that export these paths. We have to dynamically compile them, and it's a bit messy.
sethvargo added a commit to google-github-actions/auth that referenced this pull request Jul 10, 2025
The GitHub Action currently puts generated credentials into $GITHUB_WORKSPACE (/github/workspace). Unfortunately this is also the working directory of the checkout, so it's too easy to accidentally bundle the generated credentials into Docker containers, binaries, or anything that uses `*` or `.` as a build context.

In the past, we tried to move the exported credentials into RUNNER_TEMP or other directories, but it always introduced incompatibility with the various community workflows (Docker, self-hosted, etc.):

- google-github-actions/setup-gcloud#148
- google-github-actions/setup-gcloud#149
- google-github-actions/setup-gcloud#405
- google-github-actions/setup-gcloud#412

While undocumented, it appears that `/github/home` is an understood path, AND that path is mounted into Docker containers. That means we can export credentials outside of the workspace and still have them available inside the Docker container without users taking manual actions. This comes at three major costs:

1. We have to write the file into two locations. This isn't ideal, but it's also not the end of the world.

2. We would be relying on an undocumented filepath which GitHub could change at any point in the future. Since this is not part of the publicly-documented API, GitHub is within their rights to change this without notice, potentially breaking everyone/everything.

3. Because of the previous point, there are no environment variables that export these paths. We have to dynamically compile them, and it's a bit messy.
sethvargo added a commit to google-github-actions/auth that referenced this pull request Jul 11, 2025
The GitHub Action currently puts generated credentials into $GITHUB_WORKSPACE (/github/workspace). Unfortunately this is also the working directory of the checkout, so it's too easy to accidentally bundle the generated credentials into Docker containers, binaries, or anything that uses `*` or `.` as a build context.

In the past, we tried to move the exported credentials into RUNNER_TEMP or other directories, but it always introduced incompatibility with the various community workflows (Docker, self-hosted, etc.):

- google-github-actions/setup-gcloud#148
- google-github-actions/setup-gcloud#149
- google-github-actions/setup-gcloud#405
- google-github-actions/setup-gcloud#412

While undocumented, it appears that `/github/home` is an understood path, AND that path is mounted into Docker containers. That means we can export credentials outside of the workspace and still have them available inside the Docker container without users taking manual actions. This comes at three major costs:

1. We have to write the file into two locations. This isn't ideal, but it's also not the end of the world.

2. We would be relying on an undocumented filepath which GitHub could change at any point in the future. Since this is not part of the publicly-documented API, GitHub is within their rights to change this without notice, potentially breaking everyone/everything.

3. Because of the previous point, there are no environment variables that export these paths. We have to dynamically compile them, and it's a bit messy.
sethvargo added a commit to google-github-actions/auth that referenced this pull request Jul 11, 2025
The GitHub Action currently puts generated credentials into $GITHUB_WORKSPACE (/github/workspace). Unfortunately this is also the working directory of the checkout, so it's too easy to accidentally bundle the generated credentials into Docker containers, binaries, or anything that uses `*` or `.` as a build context.

In the past, we tried to move the exported credentials into RUNNER_TEMP or other directories, but it always introduced incompatibility with the various community workflows (Docker, self-hosted, etc.):

- google-github-actions/setup-gcloud#148
- google-github-actions/setup-gcloud#149
- google-github-actions/setup-gcloud#405
- google-github-actions/setup-gcloud#412

While undocumented, it appears that `/github/home` is an understood path, AND that path is mounted into Docker containers. That means we can export credentials outside of the workspace and still have them available inside the Docker container without users taking manual actions. This comes at three major costs:

1. We have to write the file into two locations. This isn't ideal, but it's also not the end of the world.

2. We would be relying on an undocumented filepath which GitHub could change at any point in the future. Since this is not part of the publicly-documented API, GitHub is within their rights to change this without notice, potentially breaking everyone/everything.

3. Because of the previous point, there are no environment variables that export these paths. We have to dynamically compile them, and it's a bit messy.
sethvargo added a commit to google-github-actions/auth that referenced this pull request Jul 11, 2025
The GitHub Action currently puts generated credentials into $GITHUB_WORKSPACE (/github/workspace). Unfortunately this is also the working directory of the checkout, so it's too easy to accidentally bundle the generated credentials into Docker containers, binaries, or anything that uses `*` or `.` as a build context.

In the past, we tried to move the exported credentials into RUNNER_TEMP or other directories, but it always introduced incompatibility with the various community workflows (Docker, self-hosted, etc.):

- google-github-actions/setup-gcloud#148
- google-github-actions/setup-gcloud#149
- google-github-actions/setup-gcloud#405
- google-github-actions/setup-gcloud#412

While undocumented, it appears that `/github/home` is an understood path, AND that path is mounted into Docker containers. That means we can export credentials outside of the workspace and still have them available inside the Docker container without users taking manual actions. This comes at three major costs:

1. We have to write the file into two locations. This isn't ideal, but it's also not the end of the world.

2. We would be relying on an undocumented filepath which GitHub could change at any point in the future. Since this is not part of the publicly-documented API, GitHub is within their rights to change this without notice, potentially breaking everyone/everything.

3. Because of the previous point, there are no environment variables that export these paths. We have to dynamically compile them, and it's a bit messy.
sethvargo added a commit to google-github-actions/auth that referenced this pull request Jul 11, 2025
The GitHub Action currently puts generated credentials into $GITHUB_WORKSPACE (/github/workspace). Unfortunately this is also the working directory of the checkout, so it's too easy to accidentally bundle the generated credentials into Docker containers, binaries, or anything that uses `*` or `.` as a build context.

In the past, we tried to move the exported credentials into RUNNER_TEMP or other directories, but it always introduced incompatibility with the various community workflows (Docker, self-hosted, etc.):

- google-github-actions/setup-gcloud#148
- google-github-actions/setup-gcloud#149
- google-github-actions/setup-gcloud#405
- google-github-actions/setup-gcloud#412

While undocumented, it appears that `/github/home` is an understood path, AND that path is mounted into Docker containers. That means we can export credentials outside of the workspace and still have them available inside the Docker container without users taking manual actions. This comes at three major costs:

1. We have to write the file into two locations. This isn't ideal, but it's also not the end of the world.

2. We would be relying on an undocumented filepath which GitHub could change at any point in the future. Since this is not part of the publicly-documented API, GitHub is within their rights to change this without notice, potentially breaking everyone/everything.

3. Because of the previous point, there are no environment variables that export these paths. We have to dynamically compile them, and it's a bit messy.
sethvargo added a commit to google-github-actions/auth that referenced this pull request Jul 11, 2025
The GitHub Action currently puts generated credentials into $GITHUB_WORKSPACE (/github/workspace). Unfortunately this is also the working directory of the checkout, so it's too easy to accidentally bundle the generated credentials into Docker containers, binaries, or anything that uses `*` or `.` as a build context.

In the past, we tried to move the exported credentials into RUNNER_TEMP or other directories, but it always introduced incompatibility with the various community workflows (Docker, self-hosted, etc.):

- google-github-actions/setup-gcloud#148
- google-github-actions/setup-gcloud#149
- google-github-actions/setup-gcloud#405
- google-github-actions/setup-gcloud#412

While undocumented, it appears that `/github/home` is an understood path, AND that path is mounted into Docker containers. That means we can export credentials outside of the workspace and still have them available inside the Docker container without users taking manual actions. This comes at three major costs:

1. We have to write the file into two locations. This isn't ideal, but it's also not the end of the world.

2. We would be relying on an undocumented filepath which GitHub could change at any point in the future. Since this is not part of the publicly-documented API, GitHub is within their rights to change this without notice, potentially breaking everyone/everything.

3. Because of the previous point, there are no environment variables that export these paths. We have to dynamically compile them, and it's a bit messy.
sethvargo added a commit to google-github-actions/auth that referenced this pull request Jul 11, 2025
The GitHub Action currently puts generated credentials into $GITHUB_WORKSPACE (/github/workspace). Unfortunately this is also the working directory of the checkout, so it's too easy to accidentally bundle the generated credentials into Docker containers, binaries, or anything that uses `*` or `.` as a build context.

In the past, we tried to move the exported credentials into RUNNER_TEMP or other directories, but it always introduced incompatibility with the various community workflows (Docker, self-hosted, etc.):

- google-github-actions/setup-gcloud#148
- google-github-actions/setup-gcloud#149
- google-github-actions/setup-gcloud#405
- google-github-actions/setup-gcloud#412

While undocumented, it appears that `/github/home` is an understood path, AND that path is mounted into Docker containers. That means we can export credentials outside of the workspace and still have them available inside the Docker container without users taking manual actions. This comes at three major costs:

1. We have to write the file into two locations. This isn't ideal, but it's also not the end of the world.

2. We would be relying on an undocumented filepath which GitHub could change at any point in the future. Since this is not part of the publicly-documented API, GitHub is within their rights to change this without notice, potentially breaking everyone/everything.

3. Because of the previous point, there are no environment variables that export these paths. We have to dynamically compile them, and it's a bit messy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants