In this PR, I update the `actions/checkout` versions. When I recently
started using this action, I was confused about whether it works with
the newest checkout action. I tested it and everything is fine. For
future users, we should display examples with the newest versions.
We need to fix the SSH keys shipped with this action:
https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/
But, we have another issue
(https://github.com/webfactory/ssh-agent/pull/108) with regards to host
keys: On self-hosted runners which are not ephemeral the known_host file
fills up with repeated entries, because every action run adds a new line
with the same host keys.
Also, on those machines, the old key will still be in the `known_hosts`
file.
IMHO this action should not be repsonsible for shipping SSH host keys,
that's too much responsibility.
This section in the code is a leftover from early days when GitHub
provided runners did not include SSH keys at all. For a long time
already, GH takes care of placing their SSH keys in their runner images.
For self-hosted runners, those people setting up the runner should fetch
and verify SSH keys themselves and put it into the `known_hosts` file.
I know this is a breaking change and is going to annoy users. But on the
other hand, there is no better opportunity to drop this feature than
with an emergency-style key revocation as today.
Closes#106, closes#129, closes#169, closes#170, closes#172.
Added support for GitHub Enterprise servers by loosening the
restrictions on the hostname portion of the deploy key comment being
"github.com" to any hostname and then using that hostname in the rest of
the config. Adjusted the regex to match the end of the line since the
comment portion is at the end. fixes#934
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 change avoids the
`Comment for (public) key '' does not match GitHub URL pattern. Not treating it as a GitHub deploy key.`
log message that was caused by inappropriate parsing of `ssh-add -L` output and confused a lot of users already.
### Problem:
Observed error on `windows-2022` ([GitHub-hosted runner](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources)) that `git` command cannot be found.
### Issue:
Cannot find git executable on on windows-2022 (GitHub-hosted runner) #136
### Solution:
This path improvement makes use of existing `path.js` to resolve and return correct `git.exe` path for Windows, leaving the executable name as it was for other operating systems.
### Caveats:
No idea how and why this `c://progra~1//git//usr//bin//git.exe` mumbo-jumbo works but it apparently did for other executables so figured it should work for `git.exe` (and it does).
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>
execSync just started a second ssh-agent. `['-k']` argument was
treated as options, it didn't have `stdio` set, so stdio was piped and
returned (and ignored).
According to https://github.com/actions/runner/issues/987, this should run the post step (cleanup.js) also when a workflow fails.
Probably most important on self-hosted runners that are not ephemeral, to terminate SSH agents from failed jobs as well.
