eric sciple
eric sciple
@TingluoHuang do you see any reason why RUNNER_TEMP shouldn't be mounted into a container action? I think that's the correct solution to fix this bug. Thoughts?
@mirobertod @AmorfEvo @EricDales @MiticoBerna could you help us understand more about your scenario. Especially interested in scenarios involving organization-level or enterprise-level runners.
> do you recall why we need to pull in the indirect dependency to evaluate job conditions? Nope. That surprises me. I do see the `success()` that is used for...
Does the ssh-key have access to both repos? Or are you using a deploy key (access to only one repo)?
Oh I see. Currently if you supply an SSH key then it's used to checkout the main repo and submodules.
Since one of the features of checkout@v2 is to persist the creds on disk to enable easier scripting authenticated git commands, I think using the provided sshkey for the main...
It looks like `ssh` allows multiple `-i identity_file` args. What do you think about being able to specify multiple ssh keys. For example: ```yaml ssh-key: | ${{ secrets.my_main_repo_deploy_key }} ${{...
> how the checkout action works today ... Is it the case that whatever implicit authentication scheme that is used provides only read-only access to the repo it's running against?...
Proposed here: https://github.com/actions/checkout/pull/190
It was a proposed change to the spec, but prevented other scenarios. As part of the discussion we figured out separate inputs `submodules-ssh-key` and `submodules-ssh-token` would be better.