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)
  • curl tool installed and accessible as curl command from the Bash interpreter
  • 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 🎉.

Installing to be continuous in a custom root group

By default and preferably, to be continuous shall be installed:

  • in the to-be-continuous root group on your GitLab server,
  • with public visibility.

If one or both of these requirements can't be met (because you're not allowed to create a root group in your organization and/or not allowed to create projects with public visibility), please read the advanced usage chapter.

Build the tracking image

Deprecated

to be continuous used to need the tracking Docker image to be successfully built and available locally in your Docker registry because it is used as a service container by all templates.

This is no longer required as in its latest versions, TBC is - by default - pulling the image from the gitlab.com public registry.

This can be overridden. For more info, please read the advanced usage chapter.

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-level 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.