For some odd reason when using runs.using=docker, GH generates the following command, which seems to work:
/usr/bin/docker run --name cd98f803720ba1e3141faa58cdbc60b9330e4_95b894 --label 4cd98f --workdir /github/workspace --rm -e INPUT_REPO-TOKEN -e INPUT_LABEL-MAJOR -e INPUT_LABEL-MINOR -e INPUT_LABEL-PATCH -e INPUT_LABEL-NONE -e INPUT_TRUNK -e INPUT_REPO-STORAGE-PATH-OVERWRITE -e INPUT_SHOULD-SET-TAG -e INPUT_SHOULD-PUSH-TAG -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_RETENTION_DAYS -e GITHUB_RUN_ATTEMPT -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_REF_NAME -e GITHUB_REF_PROTECTED -e GITHUB_REF_TYPE -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e GITHUB_STEP_SUMMARY -e RUNNER_OS -e RUNNER_ARCH -e RUNNER_NAME -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/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/semver-tag-from-pr-integration-infra/semver-tag-from-pr-integration-infra":"/github/workspace" 4cd98f:803720ba1e3141faa58cdbc60b9330e4
(for full example see here)
This is kind of weird as the the /home/runner/work/semver-tag-from-pr-integration-infra/semver-tag-from-pr-integration-infra (which is GITHUB_WORKSPACE) gets mounted as /github/workspace into the container. This should then lead the binary to fail, since it looks for $GITHUB_WORKSPACE (which is still /home/runner/...), but the repo is actually in /github/workspace.
Possilby GH behind the scenes manipulates the $GITHUB_WORKSPACE for the container to point to something else, or there is some other magic in place. For now we simply mount $GITHUB_WORKSPACE as $GITHUB_WORKSPACE.
This should have no major impact, as users which want to clone the repository into a different can always set the repo-storage-path-overwrite parameter
For some odd reason when using runs.using=docker, GH generates the following command, which seems to work:
(for full example see here)
This is kind of weird as the the
/home/runner/work/semver-tag-from-pr-integration-infra/semver-tag-from-pr-integration-infra(which is GITHUB_WORKSPACE) gets mounted as/github/workspaceinto the container. This should then lead the binary to fail, since it looks for $GITHUB_WORKSPACE (which is still /home/runner/...), but the repo is actually in/github/workspace.Possilby GH behind the scenes manipulates the $GITHUB_WORKSPACE for the container to point to something else, or there is some other magic in place. For now we simply mount $GITHUB_WORKSPACE as $GITHUB_WORKSPACE.
This should have no major impact, as users which want to clone the repository into a different can always set the
repo-storage-path-overwriteparameter