proposal: Better support for GHES

[jiminj]

Checklist

• I am using the latest version of this action.
• I have read the latest README and followed the instructions.
• I have read the latest GitHub Actions official documentation and learned the basic spec and concepts.

Describe your proposal

GHES environments support on the current version is quite limited. I already made a PR for the part of this issue, and I see several GHES related PRs are made by other contributors as well. Since I found that you marked those PRs as a target of its next release, I make the list of the found issues and features worth considering to include in the next release.

• Authentication with RSA deploy-key: GHESs often do not allow to publish pages by actions with GITHUB_TOKEN by its policy, which is similar behavior to old github.com, while the current version does not support deploy-key based authentication on GHES

• Post-cleaning step for self-hosted runners: GHESs use their own self-hosted runners instead of those served by github.com, Unlike the original github.com runner, self-hosted runners do not clean artifacts by themselves after the things are done. So there are leftovers such as:
  • working directory
  • (For deploy-key based authentication)
    • known_hosts, config, and RSA key files
    • ssh-agent process

• Publishing to cross-domain external repository: Sometimes it is required to export GHES repository content to external github.com, which is not a supported feature for now.
• Connection through SSH Proxy: Enterprise servers beyond a firewall are often limited to access external hosts via SSH (port 22), this limits the deploy-key-based approach which requires an ssh connection. github.com provides a workaround for this: Using SSH over the HTTPS port - GitHub Docs

Describe the solution you'd like

I already made PR for the deploy-key-based authentication: #680, and also ready to publish another one for features for cross-domain release and SSH, with a new ssh_proxy input field.

Not really sure about the leftover problem. The one approach should be to save the working directory's path somewhere else, and backup old known_hostsand config files. Then add a post-step to make these clean and killing ssh-agent process to prevent Address already in use errors in the next runs.

Another approach is to use chroot for easier clean-up. Didn't try, but it might require more complex setup.

Describe alternatives you've considered

No response

Additional context

Related open issues and PRs I found:

• proposal: Questionable practise of directory usage especially for GHES usage #663
• Github Enterprise Compatibility  #579
• fix: use custom path & random filename for ssh auth socket #672
• Allow GHES repository to support deploy key #680

[peaceiris]

Thank you for your proposal and for gathering current problems. And, I'm sorry for the late reply to related issues and pull-requests.

Today, I am currently confirming my permissions to the company I work at, about the use of GitHub Enterprise Cloud/Server, GitHub-hosted/self-hosted runner to test my public actions.

Now, I will start to investigate this problem, and after I get the permissions, I will test the implementations in real environments.

[peaceiris]

I have got my account on GHES now.

[jiminj]

Good, please let me know if you want to test it in other GHES environments because they are possibly running different self-hosted runner setup or policies.

[peaceiris]

My notes

Todo

• Test on a custom container cf. support: deploy key doesn't work #719