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.
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
jqcommand from the Bash interpreter
Run the GitLab Synchronization Script¶
- Create an empty
to-be-continuousroot group with
- In the
to-be-continuousroot group, generate a group access token with scopes
- Store the token in
GITLAB_TOKENenvironment variable (
export GITLAB_TOKEN="<the token>").
- 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¶
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
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.
- declare the CI/CD project variable
GITLAB_TOKENwith the previously created token (mark it as masked),
- create a scheduled pipeline (for instance every day at 2:00 am).
All other required variables shall be retrieved from GitLab CI predefined variables.
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:
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
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
as an instance CI/CD variable.
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.