Mercure-Hub: 5. GitLab CI

This documentation is part of the GitHub Actions & GitLab CI guide. You can view the complete guide here: Launch a real Mercure Hub service from your GitHub Actions or GitLab CI pipeline, run your tests against it, and automatically tear it down.

👋 Welcome to the Stackhero documentation!

Stackhero offers a fully managed Mercure-Hub cloud service designed to simplify and ensure reliable real-time data delivery. You benefit from:

• Unlimited requests and message sizes for total flexibility.
• A custom domain with integrated HTTPS security (for example, https://real-time.your-company.com).
• One-click updates to keep your hub up to date effortlessly.
• High performance and enhanced security on a private, dedicated infrastructure.
• Multiple available regions: 🇪🇺 Europe and 🇺🇸 USA for low-latency delivery.

Get started quickly: it only takes 5 minutes to launch your Mercure-Hub cloud hosting environment and start sending real-time updates to your applications.

You can save this configuration as .gitlab-ci.yml. With this setup, each pipeline run spins up a fresh real Mercure Hub for your tests.

test:
  image: ubuntu:24.04
  variables:
    STACK_NAME: "ci-mercure-hub-$CI_PIPELINE_ID-$CI_JOB_ID"
    INSTANCE: "20G"   # Change this as needed (see step 3)
    REGION: "europe"
    SERVICE_STORE: "mercure-hub"
  # STACKHERO_TOKEN comes from the CI/CD variable you created in step 1.
  script:
    - set -euo pipefail
    - curl -fsSL https://www.stackhero.io/install.sh | sh
    - apt-get update && apt-get install -y --no-install-recommends jq curl
    - STACK_ID=$(stackhero --format=script stack-create --name="$STACK_NAME")
    - echo "STACK_ID=$STACK_ID" >> deploy.env
    - SERVICE_ID=$(stackhero --format=script service-add --stack="$STACK_ID" --service-store="$SERVICE_STORE" --instance="$INSTANCE" --region="$REGION")
    - echo "SERVICE_ID=$SERVICE_ID" >> deploy.env
    - stackhero service-wait-for --service="$SERVICE_ID"
    - config=$(stackhero service-configuration-get --service="$SERVICE_ID" --format=json)
    - host=$(echo "$config" | jq -r '.configuration.domain')
    # Request the hub endpoint and check it answers.
    - curl -fsS -o /dev/null -w "%{http_code}" "https://$host/.well-known/mercure?topic=test" | grep -qE "^(200|400|401)$"
    - echo "✅ Mercure Hub is reachable from CI."
    # You can run your own test suite here using the credentials above ...
  after_script:
    - test -f deploy.env && . ./deploy.env || true
    - >
      if [ -n "${SERVICE_ID:-}" ]; then
        stackhero service-delete --service="$SERVICE_ID" --confirm
        stackhero service-wait-for --service="$SERVICE_ID"
      fi
    - >
      if [ -n "${STACK_ID:-}" ]; then
        stackhero stack-delete --stack="$STACK_ID" --confirm
      fi

On GitLab, cleanup is handled in after_script. This section is always executed, even if the job fails, ensuring your Mercure Hub resources are deleted and you are not billed for unused resources.

In GitLab, after_script runs in a fresh shell. To handle this, the script writes the service and stack IDs to deploy.env during the job and reloads them before cleanup. This ensures that even if something fails mid-job, your resources are still deleted.

That is the complete CI lifecycle for Mercure Hub: create a stack, add the service, wait, retrieve credentials, smoke-test, and always tear down. Each pipeline run gets a real, isolated service, with nothing left running when you are done. For more information about available commands and non-interactive STACKHERO_TOKEN authentication, you can refer to the full CLI documentation.