Skip to content

GitHub Actions

GitHub Actions provides a flexible and powerful way to automate workflows directly within your GitHub repository. This guide explains how to use GitHub Actions to build, deploy, and test Martini packages using different deployment models.

Overview

This repository offers reusable GitHub Actions workflows that support different deployment strategies for Martini packages:

  • Building and pushing Docker images.
  • Creating zip artifacts of packages.
  • Uploading and validating deployments on Martini instances.

These workflows are available in the martini-build-package repository.

Deployment Models

  1. Build Docker

    Builds a Docker image that contains one or more Martini packages, giving you full control over both the runtime and your application.

    1
    2
    3
    4
    5
    6
    7
    uses: docker/build-push-action@v6
    with:
      build-args: |
        MARTINI_VERSION=latest
        PACKAGE_DIR=package
      push: true
      tags: <my.container.registry.io>/<my_app>:<my_tag> 
    
    • Purpose: Package runtime + Martini packages in one image.
    • Use Case: When deploying to containerized environments.
  2. Create Artifact

    Zips all Martini packages and uploads them as an artifact that can be used in other workflows or repositories.

    1
    2
    3
    4
    uses: actions/upload-artifact@v4
    with:
      name: package
      path: package
    
    • Purpose: Share Martini packages between jobs or repositories.
    • Use Case: Build once, deploy many.
  3. Deploy

    Uploads Martini packages to a running Martini instance (local or remote), optionally validating the deployment.

    1
    2
    3
    4
    uses: lontiplatform/martini-build-pipeline-github@v2
    with:
      base_url: "http://localhost:8080"
      access_token: "myaccesstoken"
    
    • Purpose: Deploy zip artifact to Martini Server Runtime.
    • Use Case: Automated deployment pipelines.

Steps to Configure GitHub Actions

  1. Clone or Fork the Repository

    Start by cloning the sample workflows:

    1
    git clone https://github.com/lontiplatform/martini-build-package
    

    This gives you .github/workflows templates to customize in your own project.

  2. Configure Your Workflow

    Modify YAML files in .github/workflows to suit your project’s structure and environment.

    Secrets Required Usage
    base_url Yes Base URL of the Martini instance
    access_token Yes The user's access token, obtainable via Martini or through the Lonti Console
    Variable Required Usage
    package_dir No Root directory containing packages (defaults to packages if not specified)
    package_name_pattern No Regex pattern to filter which package directories to include. Defaults to .* (all directories).
    async_upload No If set to true, tolerates HTTP 504 as a success (used when uploads are handled asynchronously). Defaults to false.
    success_check_timeout No Number of polling attempts before timing out when checking package deployment status. Defaults to 6.
    success_check_delay No Number of seconds between polling attempts. Defaults to 30.
    success_check_package_name No If set, only this specific package is polled after upload. If unset, all matched packages are polled.

    Example for the deploy workflow:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    name: Example Workflow
    
    on: [push]
    
    jobs:
      upload_package:
        name: Upload package
        runs-on: ubuntu-latest
    
        steps:
          - uses: actions/checkout@v4
          - name: Upload the package
            uses: lontiplatform/martini-build-pipeline-github@v2
            with:
              base_url: "http://localhost:8080"
              access_token: "myaccesstoken"
    
  3. Deploy Packages

    Once configured, every time you push changes to the repository, GitHub Actions will automatically:

    1. Build your Martini packages.
    2. Create artifacts or Docker images.
    3. Upload and verify deployment to Martini.
    4. (Optional) Validate by hitting a test endpoint.

Make sure your repository has the necessary permissions, and that all secrets and variables are properly configured.

Additional Resources