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
-
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.
-
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. -
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. -
Deploy Packages
Once configured, GitLab Pipelines will automatically handle the build and deployment of your Martini packages according to the specified pipeline configuration.
-
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.
-
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
-
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
-
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.
-
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 thestep.yml
file if you want to override the default values. -
Advantages of Step-Based Pipelines
- More maintainable and readable pipelines
- Simpler updates through reusable building blocks
-
More Info
Refer to the full README for details.
Additional Resources
- martini-pipeline-steps (v2): GitLab step-based pipeline files for Martini
- martini-build-pipeline: Traditional Gitlab CI/CD pipelines
- GitLab Pipelines Documentation: Official GitLab documentation