Access private, third-party repo in build environment

[shawnyeager]

Having reviewed this post on accessing private repos, I’m still stick on a particular problem.

I’m attempting to access a gem via third-party, private github repo, specifically the excellent Hydejack jekyll theme. As a paid customer, I have access to the “PRO” package as a .zip archive or a gem, via ssh key provided with the .zip archive. Configuring my ~.ssh/config and adding the private key to ~.ssh/, the build works as expected locally, per these directions.

For Netlify, I’ve attempted:

1. Adding ~.ssh to my private gitlab repo
2. Adding SSH_KEY and SSH_CONFIG as build environment variables combined with a custom build command along the lines of the above post.

Both fail, as follows:

11:12:01 PM: Fetching git@hydejack:qwtel/hydejack-8-pro.git
11:12:01 PM: ssh: Could not resolve hostname hydejack: Name or service not known

This would seem to indicate that ~.ssh/config isn’t being created or read.

Does anyone have a better approach to accessing a private, third-party repo where neither tokens nor private/public keypairs are an option?

Thanks.

[fool]

hydejack isn’t a valid hostname, which seems to be the problem as far as I can tell, without seeing your .ssh/config. Could you use an FQDN there? hydejack.com or something with a dot in it?

[shawnyeager]

Thanks, @fool. My .ssh/config defines it, but it’s an unnecessary complication, certainly. I switched to a FQDN, but now I’m seeing an auth error. I think I’m getting closer.

Is it fair to assume that this is the least-bad approach to accomplishing the task of building with a sub-module gem from a third-party, private repo? I also appreciate that this is likely an edge case.

[fool]

It’s not a super-duper-edge-case; we aim to support it if not trivially

Assuming you have already tried these steps around using the SSH key:

[Common Issue] Using an SSH key via environment variable during build

Some workflows require use of an SSH private key during build - for instance, logging in to a server to restart your backend, or using git clone on a private repo during build. There are better ways to accomplish this goal for most use cases, but in case you choose to do that, below is an approach that can work. First, create an ssh key and add the public key (shorter one) to your service (e.g. on your GitHub repo settings, or in ~/.ssh/authorized_keys on your server) Then, take the private k…

and not been successful, then the submodule will likely be the best option, yes. If you want this let me know and I can configure and DM you a deploy key to use for that submodule.

[shawnyeager]

Thanks, Chris. Really appreciate it. Please do.