Skip to content

self-managed to be continuous (basic)

This page details how to install and use to be continuous (tbc) in a self-managed GitLab.

Copy tbc to your GitLab

The first thing to do is to copy the complete tbc group structure to your own GitLab.

Don't panic, we provide all required tools to initiate it for the first time, and also schedule regular updates to keep synchronized.

Pre-requisites

The GitLab Synchronization Script has the following requirements:

  • Bash interpreter
    Trivial on Linux or MacOS, tested with Git Bash on Windows (available in Git for Windows)
  • jq tool installed and accessible as jq command from the Bash interpreter

Run the GitLab Synchronization Script

  1. Create an empty to-be-continuous root group with public visibility.
  2. In the to-be-continuous root group, generate a group access token with scopes api,read_registry,write_registry,read_repository,write_repository and with Owner role.
  3. Store the token in GITLAB_TOKEN environment variable (export GITLAB_TOKEN="<the token>").
  4. Execute the following command to recursively copy the tbc group: 
    curl -s https://gitlab.com/to-be-continuous/tools/gitlab-sync/-/raw/master/gitlab-sync.sh | bash /dev/stdin --dest-api https://your.gitlab.host/api/v4 --dest-token $GITLAB_TOKEN --exclude samples,custom

That should take a while, but hopefully at the end you'll have cloned the complete to be continuous group and projects 🎉.

Build the tracking image

Every to be continuous template uses the tracking Docker image as a service container.

As a result you won't be able to run any pipeline as long as don't have any tracking image available in the registry.

Go in your local copy of the tools/tracking project, and manually click the last docker-publish job that should be pending (if it's not the case, manually start a fresh new pipeline, then click the docker-publish job when it's pending). It may happen that the publish job fails the first time: simply retry it.

We'll see later how to configure the tracking project to collect statistics about template jobs execution. For now it is unconfigured, and will not track anything.

Sync. your local copy of tbc

From this point, you can start using to be continuous templates from your GitLab. But it is highly probable that you'll want to get automatically latest updates / new templates from the original to be continuous project.

For this, you only have to create a scheduled pipeline in your local copy of the tools/gitlab-sync project:

  1. declare the CI/CD project variable GITLAB_TOKEN with the previously created token (mark it as masked),
  2. create a scheduled pipeline (for instance every day at 2:00 am).

All other required variables shall be retrieved from GitLab CI predefined variables.

Warning

From this point, you might not make any commit in any local copy of to be continuous projects because it will get overwritten every night.

If you need to modify template code, you'll have 2 options depending on your case:

  • if it's a general enhancement/fix: make a contribution to the Open Source to be continuous project and get the change through the synchronization task,
  • if it's a change specific to your company: see advanced usage

By the way, you can manually trigger a pipeline in your tools/gitlab-sync project anytime to synchronize your to be continuous copy.

Add your custom CA certificates

If your company is using non-Default Trusted Certificate Authorities to generate server certificates, it is highly probable that some to be continuous template jobs will fail because such or such tool failed validating SSL certificates.

As explained in the usage guide, each project might define a CUSTOM_CA_CERTS variable either as a group/project variable, or in its .gitlab-ci.yml file to declare the custom company Certificate Authorities.

But there is also a global way to fix this. Ask your GitLab administrator to declare DEFAULT_CA_CERTS as an instance CI/CD variable. Similar to CUSTOM_CA_CERTS, DEFAULT_CA_CERTS shall contain one or several certificates in PEM format.

Every to be continuous template job - prior to executing - determines whether a $CUSTOM_CA_CERTS or else $DEFAULT_CA_CERTS is defined and adds its content to the trusted CA certificates.