As described in https://github.com/webfactory/ssh-agent#support-for-github-deploy-keys, this action supports giving GitHub repository URLs in SSH key comments.
It will then configure git to replace different variants of how the repo can be specified with an URL pointing to a made-up hostname.
This hostname will cause dedicated SSH config to be selected, which maps back to the right github.com hostname while selecting a particular SSH key to use.
All this was written with only github.com URLs in mind, since we have a fairly good understanding of how these URLs are made up, and we know about the different variants (including the https:// scheme) that we can safely rewrite.
Now, different requests have been made to support either repo URLs outside of github.com (possibly self-hosted GitHub Enterprise), or being able to use key comments to map keys not to repositories, but whole GitHub organisations.
In general, I'd be open to support this, but we would need to find patterns that cover a sufficiently broad range of repo URLs, figure out how flexible/generic the Git .insteadof configuration can/needs to be and how to avoid this becoming a maintenance burden.
As described in https://github.com/webfactory/ssh-agent#support-for-github-deploy-keys, this action supports giving GitHub repository URLs in SSH key comments.
It will then configure
gitto replace different variants of how the repo can be specified with an URL pointing to a made-up hostname.This hostname will cause dedicated SSH config to be selected, which maps back to the right
github.comhostname while selecting a particular SSH key to use.All this was written with only
github.comURLs in mind, since we have a fairly good understanding of how these URLs are made up, and we know about the different variants (including thehttps://scheme) that we can safely rewrite.Now, different requests have been made to support either repo URLs outside of
github.com(possibly self-hosted GitHub Enterprise), or being able to use key comments to map keys not to repositories, but whole GitHub organisations.In general, I'd be open to support this, but we would need to find patterns that cover a sufficiently broad range of repo URLs, figure out how flexible/generic the Git
.insteadofconfiguration can/needs to be and how to avoid this becoming a maintenance burden.