Meilisearch: GitHub Actions & GitLab CI
Lancez un véritable service Meilisearch depuis votre pipeline GitHub Actions ou GitLab CI, exécutez vos tests dessus, puis supprimez-le automatiquement
Bienvenue sur la documentation de Stackhero !
Si vous recherchez un moteur de recherche puissant et simple à utiliser, le service Meilisearch cloud de Stackhero est un excellent choix. Voici ce que vous pouvez attendre :
- Nom de domaine personnalisable avec sécurité HTTPS intégrée.
- Mises à jour sans effort, il suffit d'un clic.
- Performance élevée et sécurité renforcée grâce à votre propre VM privée et dédiée.
Vous souhaitez démarrer rapidement ? Essayez la solution Meilisearch cloud hosting de Stackhero en seulement 5 minutes. Elle est conçue pour vous faire gagner du temps et simplifier au maximum votre configuration !
Ce guide vous explique comment exécuter un service Meilisearch réel et dédié dans votre pipeline CI avec GitHub Actions ou GitLab CI. En suivant ces étapes, vous pouvez tester votre code sur une instance Meilisearch active dans des conditions proches de la production, sans avoir à utiliser de mocks ou de simulations. Meilisearch is a fast, open source, typo-tolerant search engine that delivers instant, relevant results out of the box.
À chaque exécution de votre pipeline, une nouvelle instance Meilisearch est créée. Vos tests interagissent donc avec le même type de service que vos utilisateurs en production. Le workflow crée automatiquement une stack temporaire, ajoute Meilisearch, attend qu'il soit prêt, récupère les identifiants générés, lance un smoke test avec curl, puis nettoie toujours tout à la fin de l'exécution.
Vous utiliserez le Stackhero CLI, un outil en ligne de commande autonome qui permet de lancer et gérer des services Stackhero de façon simple et rapide.
1. Créez un access token et stockez-le comme secret CI
Pour permettre au CLI de fonctionner sans interaction, vous aurez besoin d'un access token (format : usr-xxxxxx:tokenId). Il suffit de créer ce token une seule fois, puis de l'ajouter à votre pipeline CI comme secret sécurisé et chiffré.
- Créez le token : Sur votre tableau de bord Stackhero, cliquez sur votre photo de profil en haut à droite, allez dans Votre compte, puis Access tokens, et cliquez sur Créer un token.
- Pour GitHub Actions : Dans votre dépôt, allez dans Settings > Secrets and variables > Actions > New repository secret, et saisissez le token sous le nom
STACKHERO_TOKEN. - Pour GitLab CI : Dans votre projet, allez dans Settings > CI/CD > Variables > Add variable, définissez la clé sur
STACKHERO_TOKEN, puis cochez Masked (et Protected si votre CI ne s'exécute que sur des branches protégées).
N'ajoutez jamais votre access token directement dans le fichier YAML de votre pipeline. S'il est présent dans le YAML, il pourrait être exposé à toute personne ayant accès au dépôt et apparaître dans les logs de build. Le stocker comme secret CI garantit qu'il reste chiffré et masqué, assurant la sécurité de votre token.
2. Le script de cycle de vie
Voici un exemple complet de script qui gère tout le cycle de vie du service. Il montre à quel point la configuration est simple, avec seulement quelques commandes. Vous pouvez copier le YAML prêt à l'emploi pour votre plateforme dans les sections ci-dessous.
#!/bin/bash
set -euo pipefail
# STACKHERO_TOKEN est fourni par le secret CI, le CLI le détecte automatiquement.
stackName="ci-meilisearch-$$" # Nom de stack unique pour chaque exécution
serviceStore="meilisearch" # Le store du service Meilisearch
instance="10G" # Modifiez si besoin (voir étape 3)
region="europe" # Nom de la région (voir stackhero regions-list)
# 1. Installer le CLI sur le runner
curl -fsSL https://www.stackhero.io/install.sh | sh
# 2. Installer le client nécessaire pour le smoke test (jq + curl sont la base)
apt-get update && apt-get install -y --no-install-recommends jq curl
# 3. Créer une stack dédiée pour cette exécution
stackId=$(stackhero --format=script stack-create --name="$stackName")
echo "Stack créée : $stackId"
# 4. Ajouter Meilisearch et récupérer son service id
serviceId=$(stackhero --format=script service-add \
--stack="$stackId" \
--service-store="$serviceStore" \
--instance="$instance" \
--region="$region")
echo "Service ajouté : $serviceId"
# 5. Attendre que le service soit opérationnel (cela peut prendre quelques minutes)
stackhero service-wait-for --service="$serviceId"
# 6. Lire la configuration (contient les identifiants générés)
config=$(stackhero service-configuration-get --service="$serviceId" --format=json)
# 7. Extraire les identifiants nécessaires
host=$(echo "$config" | jq -r '.configuration.domain')
# 8. Smoke test : Call the Meilisearch health endpoint.
curl -fsS "https://$host/health" | grep -q '"status":"available"'
echo "✅ Meilisearch est accessible depuis la CI."
L'étape de suppression, qui efface le service, attend sa suppression puis supprime la stack, est détaillée dans les sections spécifiques à chaque plateforme ci-dessous. Cette méthode garantit que le nettoyage est toujours effectué, même si un smoke test échoue.
Une stack ne peut être supprimée que si elle est vide. Supprimez toujours le service en premier et attendez sa suppression, puis supprimez la stack. La commande
service-wait-forgarantit que le service est bien en cours d'exécution ou supprimé avant de continuer, c'est donc l'outil adapté pour attendre la suppression.
3. Choisissez la taille d'instance
Les exemples ci-dessous utilisent par défaut l'instance d'entrée de gamme 10G pour Meilisearch. C'est un choix fiable pour la plupart des usages, mais vous pouvez l'adapter selon vos besoins. Pour voir toutes les tailles d'instances disponibles pour Meilisearch, exécutez :
# La colonne NAME indique la valeur à passer à --instance
stackhero instances-store-list --service-store=meilisearch
4. GitHub Actions
Pour commencer, enregistrez le contenu suivant dans .github/workflows/ci.yml. Désormais, chaque push et pull request lancera des tests sur une vraie instance Meilisearch.
name: CI avec Meilisearch
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
env:
STACKHERO_TOKEN: ${{ secrets.STACKHERO_TOKEN }}
STACK_NAME: ci-meilisearch-${{ github.run_id }}-${{ github.run_attempt }}
INSTANCE: "10G" # Modifiez si besoin (voir étape 3)
REGION: europe
steps:
- uses: actions/checkout@v4
- name: Installer le Stackhero CLI et le client
run: |
curl -fsSL https://www.stackhero.io/install.sh | sh
apt-get update && apt-get install -y --no-install-recommends jq curl
- name: Créer le service Meilisearch
run: |
set -euo pipefail
STACK_ID=$(stackhero --format=script stack-create --name="$STACK_NAME")
echo "STACK_ID=$STACK_ID" >> "$GITHUB_ENV"
SERVICE_ID=$(stackhero --format=script service-add \
--stack="$STACK_ID" \
--service-store="meilisearch" \
--instance="$INSTANCE" \
--region="$REGION")
echo "SERVICE_ID=$SERVICE_ID" >> "$GITHUB_ENV"
stackhero service-wait-for --service="$SERVICE_ID"
- name: Exécuter les tests sur Meilisearch
run: |
set -euo pipefail
config=$(stackhero service-configuration-get --service="$SERVICE_ID" --format=json)
host=$(echo "$config" | jq -r '.configuration.domain')
# Call the Meilisearch health endpoint.
curl -fsS "https://$host/health" | grep -q '"status":"available"'
echo "✅ Meilisearch est accessible depuis la CI."
# Vous pouvez lancer votre propre suite de tests ici avec les identifiants ci-dessus ...
- name: Nettoyage (toujours, même en cas d'échec)
if: always()
run: |
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
L'étape de nettoyage utilise if: always() pour s'assurer qu'elle s'exécute dans tous les cas, garantissant la suppression de votre instance Meilisearch et évitant toute facturation pour des ressources inutilisées.
5. GitLab CI
Vous pouvez enregistrer cette configuration sous .gitlab-ci.yml. Avec ce setup, chaque pipeline crée une nouvelle instance Meilisearch pour vos tests.
test:
image: ubuntu:24.04
variables:
STACK_NAME: "ci-meilisearch-$CI_PIPELINE_ID-$CI_JOB_ID"
INSTANCE: "10G" # Modifiez si besoin (voir étape 3)
REGION: "europe"
SERVICE_STORE: "meilisearch"
# 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')
# Call the Meilisearch health endpoint.
- curl -fsS "https://$host/health" | grep -q '"status":"available"'
- echo "✅ Meilisearch 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 Meilisearch et évite toute facturation inutile.
Sur GitLab,
after_scripts'exécute dans un shell vierge. Pour gérer cela, le script écrit les IDs du service et de la stack dansdeploy.envpendant 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 Meilisearch : 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.