Skip to content

GitLab Pipelines

GitLab Pipelines provide a powerful solution for continuous integration and deployment (CI/CD) within your GitLab environment. This guide explains two approaches for building and deploying Martini packages using GitLab CI/CD: the traditional .gitlab-ci.yml approach and GitLab's new step-based pipeline approach introduced in the martini-pipeline-steps repository.

Overview

GitLab Pipelines allow you to automate the build and deployment of Martini packages directly from your GitLab repository and to build Docker images with the latest Martini Runtime bundled with your packages. You can now choose between:

  • Traditional CI/CD method using include in the .gitlab-ci.yml
  • New GitLab CI/CD step-based approach using reusable pipeline steps

Traditional CI/CD Method

Steps to Configure GitLab Pipelines

  1. Access the GitLab Pipelines Code

    The configuration code for the legacy GitLab Pipelines is available on Lonti's GitLab account. You can access it here. The code is public and can be invoked directly by your GitLab Pipeline.

  2. Reference the Code in Your Pipeline

    Clone or fork the repository from GitLab:

    1
    git clone git@gitlab.com:lonti/martini-build-pipeline.git

    Follow the instructions in the repository to integrate the code with your GitLab CI/CD configuration. This typically involves copying the .gitlab-ci.yml file into your own repository.

  3. Configure Your Pipeline

    Adjust the pipeline configuration to fit your repository and deployment needs. Set the following environment variables in your project:

    Variable Required Description
    BASE_URL Yes Base URL of the target Martini instance.
    ACCESS_TOKEN Yes Token used to authenticate with the target Martini instance.
    PACKAGE_NAME_PATTERN No Regex pattern to filter packages. Defaults to .*
    PACKAGE_DIR No Directory containing packages to upload. Defaults to packages.
    ASYNC_UPLOAD No If true, tolerate HTTP 504 responses and fallback to polling. Defaults to false.
    SUCCESS_CHECK_TIMEOUT No Number of polling attempts. Defaults to 6.
    SUCCESS_CHECK_DELAY No Delay between polling attempts in seconds. Defaults to 30.
    SUCCESS_CHECK_PACKAGE_NAME No If specified, only this package will be polled for STARTED status.

  4. Deploy Packages

    Once configured, GitLab Pipelines will automatically handle the build and deployment of your Martini packages according to the specified pipeline configuration.

  5. Build Docker Image

    Add your Dockerfile to your GitLab repository. Example:

    1
2
3
4
5
6
7
8
    ARG MARTINI_VERSION=latest

FROM lontiplatform/martini-server-runtime:${MARTINI_VERSION}

ARG PACKAGE_DIR=packages
RUN mkdir -p /data/packages
COPY ${PACKAGE_DIR} /data/packages/
COPY conf /data/conf/

    The pipeline will automatically manage all build steps and push the resulting image to the configured container registry.

  6. More Info

    Refer to the full README for details.

GitLab Step-Based CI/CD Approach

GitLab now supports step-based CI/CD pipelines that promote modular, reusable components called steps. This new approach simplifies pipeline definitions and encourages reuse across projects.

Lonti provides a new repository with step definitions to simplify working with Martini:

How to Use the New Steps

  1. Reference Steps in Your Pipeline

    Use the step keyword to import the steps into your project:

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
    stages:
- upload_package
- execute_api

upload_package:
stage: upload_package
run:
    - name: upload_package
    step: gitlab.com/lonti/martini-pipeline-steps/-/upload_package@v2
    inputs:
        SUCCESS_CHECK_PACKAGE_NAME: sample-package
        PACKAGE_NAME_PATTERN: ^sample-package


execute_api:
stage: execute_api
run:  
    - name: execute_api
    step: gitlab.com/lonti/martini-pipeline-steps/-/execute_api@v2

  2. Choose the Steps You Need

    Available step files include upload_package and execute_api. You can customize your pipeline by combining these modular step files.

  3. Set Required Variables

    Similar to the legacy pipeline, ensure the following variables are defined in your project:

    Variable Usage
    CI_BASE_URL URL of the Martini instance where artifacts will be uploaded
    CI_ACCESS_TOKEN Token used for authentication to the server
    PACKAGE_DIR Directory where the packages are loacated (this is set in the `.gitlab-ci.yml)

    Other variables like ASYNC_UPLOAD, SUCCESS_CHECK_TIMEOUT and etc. will need to be set in the step.yml file if you want to override the default values.

  4. Advantages of Step-Based Pipelines

    • More maintainable and readable pipelines
    • Simpler updates through reusable building blocks

  5. More Info

    Refer to the full README for details.

Additional Resources