The current docs mention only `docker/build-push-action` in conjunction
with deploy keys.
This might mislead users to believe, that this only applies to said
Action. But the concept applies to all workflows that somehow use
`docker build` with deploy keys.
This PR clarifies the relevant section.
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
On my self-hosted Windows runners, the `git`, `ssh-agent`, and `ssh-add`
commands are not located in the locations that are currently hard-coded
in `paths.js`.
With this PR, I am able to get this action to work on my runners as
follows:
```yaml
- uses: webfactory/ssh-agent@...
with:
ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
git-cmd: git
ssh-agent-cmd: ssh-agent
ssh-add-cmd: ssh-add
```
Update `actions/checkout` to `@v3` and make it syntactically correct in order to allow copy and paste.
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
This commit adds the new `log-public-key` action input.
Closes#122 (contains the suggested changes plus a few tweaks and documentation), fixes#100.
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
This change adds some extra clarification to the documentation to show how to setup the `docker/build-push-action` step with this action. This is very helpful when using buildkit's `RUN --mount=type=ssh`. We found this to be a little confusing and the GH issues we found on the matter didn't help!
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
* Add note about using cargo with private dependencies
* Update doc to mention Windows only
* Add alternative workaround
* Create extra main section for tips and information regarding different languages/tools
Co-authored-by: Matthias Pigulla <mp@webfactory.de>
Thanks to @thommyhh for this contribution!
Unless the `SSH_AUTH_SOCK` is configured explicitly, this change will make the SSH agent use a random file name for the socket. That way, multiple, concurrent SSH agents can be used on non-ephemeral, self-hosted runners.
A new post-action step will automatically clean up the running agent at the end of a job.
Be aware of the possible security implications: Two jobs running on the same runner might be able to access each other's socket and thus access repositories and/or hosts.
