Fetching additional repositories

The shortcut to fetching additional repositories.

Well established, mature projects often span several repositories. To successfully produce a build in the CI pipeline, source code from multiple repositories must be fetched.

Snake CI provides a seamless way to clone additional repositories during job execution by automatically managing access keys so that CI pipeline can have access to the same repositories as the user who triggered the pipeline (either via the UI or with git push).

By default, cloning repositories via the SSH protocol from a remote host requires interactive confirmation that this remote host is trusted.

This manual verification causes job execution to stop, but it can be safely skipped if the project requires additional repositories from the same Bitbucket instance.

The simplest way to skip verification is to provide a customized SSH command for git by defining GIT_SSH_COMMAND in the snake-ci.yaml file. This variable can be defined once in the global variables section, like this:

variables:
    GIT_SSH_COMMAND: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

The following example shows how this approach can be used to clone additional repositories to the working directory in the CI job:

stages:
    - prepare
    - build
    - deploy

variables:
    GIT_SSH_COMMAND: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

fetch dependencies:
    stage: prepare
    commands:
        - apk --update add openssh git
        - git clone ssh://git@bitbucket.company:7999/libs/lib-a.git libs/a
        - git clone ssh://git@bitbucket.company:7999/libs/lib-b.git libs/b

build project:
    stage: build
    commands:
        - apk add --update npm
        - npm run build

deploy on production:
    stage: deploy
    only:
        variables:
            - $DEPLOY_PRODUCTION
    commands:
        - apk --update add openssh git
        - git clone ssh://git@bitbucket.company:7999/infra/secrets.git secrets
        - kubectl --kubeconfig=secrets/kubconfig apply -f deployment.yaml

In this example, we have 3 stages: prepare, build, and deploy:

  • The prepare stage contains a single fetch dependencies job that clones two additional repositories with dependencies used in the project.

  • The build stage will perform project build using gradle.

  • And finally, the deploy stage will be executed only if the $DEPLOY_PRODUCTION variable is specified.

Note, that in the deploy on production job, the additional repository named configs will be cloned.

This repository may contain sensitive information such as production deployment keys.

Snake CI automatically protects access to this repository by limiting access to the users who have access to this repository via standard Bitbucket access rules.

This means that the deploy on production job fails if a user without actual access to the secret repository triggers pipeline with the $DEPLOY_PRODUCTION variable specified.

Last modified October 21, 2020