Private Repository Dependencies

Build Environment
,
1

We are currently evaluating circleci for use. To do this we are trying to build a few of our golang application. One of these applications which is private GitHub repository depends on a package that we built which is also a private repository in our same GitHub organization.

The issue is that circleci cannot build because it cannot get access to the other package.

In order to give access from the application to the package we generated an SSH key pair locally and in the application repository went to the SSH permissions and added it there. We then took the public key from that SSH key pair and added it as a deploy key to the package GitHub repository.

Below is the error that we are getting with building the application with {package} replacing the private library repository uri.

#!/bin/bash -eo pipefail
dep ensure
ensure Solve(): no valid source could be created:
failed to set up sources from the following URLs:
{package}
: remote repository at {package} does not exist, or is inaccessible: : exit status 128
failed to set up sources from the following URLs:
ssh://git@{package}
: remote repository at ssh://git@{package} does not exist, or is inaccessible: : exit status 128
failed to set up sources from the following URLs:
git://{package}
: remote repository at git://{package} does not exist, or is inaccessible: : exit status 128
failed to set up sources from the following URLs:
{package}
: remote repository at {package} does not exist, or is inaccessible: : exit status 128
Exited with code 1

We were able to hack in a fix for this previously (we have since removed) by taking an existing user on the team with access to both repositories and setting them as the preferred key in the checkout ssh keys permissions. We did not want this to be the solution because then our build system depends on a specific user. The thought of creating a machine user crossed our minds but we would prefer to use SSH keys.

1 Like
2

Hi Jake,

Thank you for your patience. A machine user is just an SSH key that has access to more than one repo (but not all of them) and it sounds like that is exactly what you are looking for.

You mention you don’t want to use one, so I’m wondering if this is an opportunity to make our documentation clearer. Can you explain what your understanding of a machine user is, so we can make sure we are on the same page?

1 Like
3

We just went ahead and created a machine user.

We would have rather just managed these using SSH keys, rather than creating a user is what I am getting at.