Initial problem

A typical example:

• Trivy scan: checks Docker images for CVEs

• Slack message: sends results

• Jira tickets: should be updated automatically

The old approach looked like this (simplified):

audit-image-app-1:
stage: audit
variables:
CI_IMAGE: $REGISTRY/$IMAGE_NAME:$IMAGE_TAG
script:
- docker pull $CI_IMAGE
- trivy image --no-progress --exit-code 1 $CI_IMAGE
- …

Problem: Each pipeline contained individual YAML code. Changes (e.g., adjustments to Trivy) meant that 20+ repositories had to be adjusted and tested.

Idea & goal: Toolbox + Shared CI

The core idea:

• Toolbox (Docker image) → contains tasks such as JiraUpdateComponent, JiraAuditReportTrivy, SlackSend

• Shared CI → integrates the toolbox into all projects by calling the toolbox's Docker image with configuration parameters.

• Pipeline → imports the shared logic from SHARED-CI

This creates a clear separation:

• Business logic in the Docker container

• CI/CD pipeline in the shared layer and in the project remain minimal

Example (shared CI):

include:
- project: group/subgroup/shared-ci
file: .gitlab-ci.yml
ref: master

update_jira_ticket:
stage: deploy
image: docker:24.0.5
services:
- docker:24.0.5-dind
script:
- echo "TASK=JiraUpdateComponent" > saved.env
- docker run --env-file saved.env gitlab-registry.dev/.../toolbox:motel-one

Implementation of the toolbox

The toolbox is written in Deno/TypeScript and follows a task-based architecture:

switch (TASK) {
case Tasks.SlackSend:
await sendSlack(SLACK_SEND_MESSAGE, SLACK_SEND_CHANNEL);
break;
case Tasks.JiraUpdateComponent:
await addComponentToTicket();
break;
case Tasks.JiraAuditReportTrivy:
await runAuditReportTask();
break;
}

Branch structure

• main: Basic tasks

• motel-one: Includes project-specific adjustments (e.g., JiraUpdateComponent)

• Feature branches: Teams can add their own tasks

Example tasks

1. JiraUpdateComponent

   • Reads commit or MR names

   • Extracts Jira issue key from the commit or merge request name (ABC-123)

   • Automatically updates ticket metadata

2. JiraAuditReportTrivy

   • Scheduled pipeline (cron: Monday, Tuesday, and Thursday at 9 a.m.)

   • Performs Trivy scan for an app

   • Automatically creates Jira tickets for each CVE found instead of just Slack messages

3. SlackSend

   • Easy integration for notifications to a Slack channel

The setting in practice at Motel One

The workflow today:

1. Build & Push → Toolbox is stored in the GitLab Container Registry as a Docker image

2. Shared CI → Uses this Docker image and runtime to execute the business logic in the pipeline

3. Project pipeline → Imports the pipeline with the business logic from the shared CI and passes parameters

Comparison:

• Previously: Slack message → directly in pipeline via Bash

• Today: Slack message → shared pipelines → Toolbox task SlackSend

  → The same applies to Jira updates and CVE reports.

Implementation challenges

• Testing: Changes to shared CI can break all pipelines → Solution: Feature branch in shared CI + project-based testing

• Artifacts: Transfer of JSON files between Toolbox and pipeline → Solution via GitLab API and artifact handling

Future Outlook

The Toolbox is currently a proof of concept. The next steps are as follows:

• Refactoring the code structure

• Involvement of additional developers

• New tasks for the Toolbox

Conclusion

The pipeline toolbox at Motel One shows how DevOps teams can reduce complexity:

• Modularity through Docker tasks

• Reusability through shared CI

• Automation instead of copy & paste

The result: fewer errors. Faster adjustments. A central location for further development and optimization in the CI/CD area. More focus on the essentials. This saves time and resources overall, which can be put to much better use elsewhere in the project.