Let's say you have a project depending on a private git
repository that your CI server needs access to, or a third-party developer.
In our case, it's an Elixir dependency in our Mix.exs
file that looks like this:
{:my_private_dependency, git: "[email protected]:original-organization/my_private_dependency.git", ref: "46de95907bc4e636acd798ba19c43138f72199de"},
The approach to take differs slightly depending on which of these two scenarios apply:
- Scenario 1: I can arrange to create a "deploy key" (new SSH keypair) that will have read access the original repository (typical for CI workflows).
- Scenario 2: I can create a private copy of the repository I depend on, hosted at a different address than the original. (typical for private "forks")
In your favorite unix shell, provision a new SSH key. Add a comment to the key so that you can remind yourself what the key is for.
ssh-keygen -t rsa -b 4096 -C "[email protected]:original-organization/my_private_dependency.git" -f ~/.ssh/my_private_dependency
This will generate a public key at ~/.ssh/my_private_dependency.pub which you can add as a Deployment Key for my_private_dependency
project
on github (something like https://github.com/[username_or_org_name]/[project_name]/settings/keys
)
For a CI scenario, your next step would be to place the private key as a secret on the CLIENT repository, and add that file
to the ~/.ssh/
directory as part of your CI workflow. Finally, you'll want to add these lines to your ~/.ssh/config
You'll want to update your ~/ssh/config
as part of your CI workflow. You'll add:
Host my_private_dependency.github.com
HostName github.com
IdentityFile ~/.ssh/my_private_dependency
IdentitiesOnly yes
The next step is to inform git that you want it to look for the repository at this special pseudo-host:
git config --global url."git@my_private_dependency.github.com:original-organization/my_private_dependency.git".insteadOf [email protected]:original-organization/my_private_dependency.git
Then, when you fetch your dependencies, git and ssh will translate any requests on that machine for to use the alternate credentials against the fake hostname.
In a Github workflow, you can store the private key as a secret and accomplish all of the above with shell commands. But there is a Github action that basically automates all of the steps once you've provisioned the private key as a secret. See Webfactory ssh-agent action for more information. Under the hood, it basically does what I've described, although it explicitly relies on the SSH key's comment field that I noted above.
Let's say the private repository is available to you, but not at the original URL. You've created a new repo on, for example, Github and pushed a version of the original repo there.
In this case, assuming you connect to Github (or your own Git host) via SSH, you simply need to arrange for the instead-of mapping:
git config --global url."[email protected]:our-private-organization/my_private_dependency.git".insteadOf [email protected]:original-organization/my_private_dependency.git