Private Repositories

The workers Solano CI starts for your build use a distinct SSH keypair (the worker SSH identity) to ensure that accesses to your repositories are secure and traceable. See below for details on submodules.

The worker SSH identity is specific to each Solano Organization.

This allows build workers to make authorized transactions, like installing package dependencies (via Bundler, PIP, or another dependency manager) from private repositories.

If you need to add to the SSH client configuration or default list of known hosts, read about SSH configuration.

Follow these steps to authorize the Worker public key:

  1. Find your worker public key:

    Web UI

    To find the worker SSH identity for your Solano Organization:

    1. Open the nav menu in the upper right toolbar.
    2. Choose “Organizations”
    3. Pick the organization you want to work with.
    4. Click on “Organization Settings” for that organization.
    5. Click on “Worker SSH Identity” item in the menu on the left

    CLI

    Run the solano account command:

    $ solano account
    

    You should see a section called “Test Worker SSH Identity”, with an SSH public key.

    You may need to specify an organization to query for the Test Worker SSH Identity:

    $ solano account --org=<Organization Name>
    
  2. Authorize this SSH public key to pull from the private repos hosting your private gems.

    Solano CI currently uses the same key for all gem installs for a given Solano organization. If you use GitHub, see the next section.

  3. Make sure your dependency files use an “scp” or ssh:// style URL for your private repo. For example: git@github.com:user/repo.git. git:// URLs are requested without any authentication – they only work for public repos.

Submodules

If you are using functionality such as git submodules there is an additional “gotcha”. The checkout process in a build worker must be able to run unattended. This means that if the submodule configuration points to another repository, the worker must be able to authenticate to it as well. Otherwise, the build will often hang with the SCM client waiting for user input of name and password.

There are three options:

  1. Authorize the SSH Worker Identity to access the remote repository
  2. Use an unauthenticated HTTP or HTTPS URL
  3. Use an authenticated HTTP or HTTPS URL (e.g. HTTP basic or OAuth)

By default, Solano CI will ignore HTTP and HTTPS URLs for git submodules in order to avoid builds hanging when run unattended. For options two and three above, you will need to enable support for HTTP in git modules. You can force HTTP submodule support with the following option in your solano.yml:

submodules: true

If you are using a private repository with HTTP URLs, you can use HTTP basic authentication and embed the username and password in the submodule configuration.

If you are using Github or another provider with similar support for OAuth, then we recommend a different approach. With Github, you can generate an OAuth token for the submodule and embed it instead:

https://<token>x-oauth-basic@github.com/owner/repo.git

See below for more details on GitHub and its support for OAuth tokens.

GitHub

Solano CI uses the same SSH key for all requests from workers for private dependencies into a given Solano organization’s builds.

If your dependencies come from GitHub, and you have multiple repos to pull from, we recommend that you create a bot user and authorize the worker identity public key for the user. You can then give the bot user read access to your dependency repos.

If you are using Github organizations, read GitHub’s setup instructions and more details on read-only permissions.

If you have configured your Github Linkage the GITHUB_OAUTH_TOKEN environment variable will also be automatically set in the worker. This value can be used to construct URLs to retrieve files from Github, for instance in a setup hook.

For information on Github OAuth token support, see Github’s blog post.