Mercure-Hub: 5. GitLab CI

Cette documentation fait partie du guide GitHub Actions & GitLab CI. Consultez le guide complet ici : Lancez un véritable service Mercure Hub depuis votre pipeline GitHub Actions ou GitLab CI, exécutez vos tests dessus, puis supprimez-le automatiquement.

👋 Bienvenue sur la documentation de Stackhero !

Stackhero propose un service Mercure-Hub cloud entièrement managé, conçu pour simplifier et fiabiliser la diffusion de données en temps réel. Vous bénéficiez de :

• Requêtes et tailles de messages illimitées pour une flexibilité totale.
• Un domaine personnalisé avec HTTPS intégré (par exemple, https://real-time.votre-entreprise.com).
• Des mises à jour en un clic pour garder votre hub à jour sans effort.
• Une performance élevée et une sécurité renforcée sur une infrastructure privée et dédiée.
• Plusieurs régions disponibles : 🇪🇺 Europe et 🇺🇸 USA pour une diffusion à faible latence.

Démarrez rapidement : il suffit de 5 minutes pour lancer votre environnement Mercure-Hub cloud hosting et commencer à envoyer des mises à jour en temps réel à vos applications.

Vous pouvez enregistrer cette configuration sous .gitlab-ci.yml. Avec ce setup, chaque pipeline crée une nouvelle instance Mercure Hub pour vos tests.

test:
  image: ubuntu:24.04
  variables:
    STACK_NAME: "ci-mercure-hub-$CI_PIPELINE_ID-$CI_JOB_ID"
    INSTANCE: "20G"   # Modifiez si besoin (voir étape 3)
    REGION: "europe"
    SERVICE_STORE: "mercure-hub"
  # STACKHERO_TOKEN provient de la variable CI/CD créée à l'étape 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 est accessible depuis la CI."
    # Vous pouvez lancer votre propre suite de tests ici avec les identifiants ci-dessus ...
  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

Sur GitLab, le nettoyage s'effectue dans after_script. Cette section est toujours exécutée, même si le job échoue, ce qui garantit la suppression de vos ressources Mercure Hub et évite toute facturation inutile.

Sur GitLab, after_script s'exécute dans un shell vierge. Pour gérer cela, le script écrit les IDs du service et de la stack dans deploy.env pendant le job, puis les recharge avant le nettoyage. Ainsi, même en cas d'échec en cours de job, vos ressources sont bien supprimées.

Voilà le cycle CI complet pour Mercure Hub : création d'une stack, ajout du service, attente, récupération des identifiants, smoke test, et nettoyage systématique. Chaque exécution de pipeline bénéficie d'un service réel et isolé, sans rien laisser tourner après coup. Pour plus d'informations sur les commandes disponibles et l'authentification non interactive avec STACKHERO_TOKEN, vous pouvez consulter la documentation CLI complète.