# Continuous Integration and Delivery

See all pages under ./CID here.

Continuous Integration and Delivery (aka. CID or CI/CD) is here to compile code, run tests, and integrate projects in an continuous and automated manner.

## State of Our Current CI/CD Infrastructure

### Configuration

We are using a self-hosted Gitlab CI system on https://pep-security.lu/gitlab with multiple Runners.

Projects which are hosted on our Gitea are mirrored to the gitlab under the CID/Mirrors namespace.

Please read our Gitlab CI Primer to become more familiar with the underpinnings of this setup.

The Gitlab Runner’s configuration and setup is defined in an Ansible Repository.

We have two different environments for running CI. Namely, jobs can be run either inside Docker containers, or inside a Debian 10 KVM.

When using Docker, we have a self-hosted registry for storing and retrieving images at this hostname: dockerreg.pep.security

NOTE: We are explicitly not using any 3rd party Container Registry to store the Docker Images we produce.*

### Defined Processes

We have some processes defined which when applied makes integration between projects possible, and CI easier to implement.

### Using CI/CD in Your Project

• Create .gitlab-ci.yml manifest file in the root of your repository.
• If you want to run in docker, then specify via the “tags” keyword in each of your jobs with the value ["docker"]
• Commit the .gitlab-ci.yml file and push to the remote, and the pipeline will begin to run.

Here’s an example .gitlab-ci.yml file:

image: debian:10

build:
stage: build
tags: ["docker"]
script:
- make -j\$(nproc)
test:
stage: test
tags: ["docker"]
script:
- make test