Variables GitLab CI depuis Crunu, liées par id_tokens

Ce que fait Crunu dans GitLab CI

Un job lance votre commande via crunu run. L’agent crunu se connecte avec un jeton de service, vérifie les signatures, déchiffre les variables en mémoire et lance la commande avec elles. Rien n’est écrit sur le disque.

crunu run --env web-app/staging -- npm test

Le jeton ne reçoit que les environnements que vous accordez. Avec une liaison CI (OIDC), GitLab remet au job un jeton dont l’audience est votre serveur Crunu, et le jeton Crunu ne fonctionne qu’accompagné de celui-ci, pour le chemin de projet, la ref et l’environnement que vous avez définis. crunu lit lui-même le jeton GitLab dans CRUNU_ID_TOKEN.

Configuration

1. Dans Crunu, ouvrez Service tokens et choisissez New service token. Accordez les environnements dont le job a besoin. Le jeton n’est affiché qu’une seule fois.
2. Dans GitLab, ouvrez Settings → CI/CD → Variables et ajoutez CRUNU_TOKEN comme variable masquée et protégée.
3. Ajoutez CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 et CRUNU_BINARY_SHA256 avec les valeurs du bloc CI setup de la page du jeton. Dans le cloud, CRUNU_SERVER vaut https://app.crunu.com.
4. Facultatif : ajoutez une liaison CI (OIDC) sur la page du jeton. Choisissez le fournisseur GitLab et définissez project_path, ref, ref_type et, pour un jeton de production, environment.

Exemple de job

L’image du job doit contenir sh et curl ou wget. Les images node, python et alpine les contiennent.

test:
  image: node:24
  id_tokens:
    CRUNU_ID_TOKEN:
      aud: https://app.crunu.com   # your Crunu server; only if the token has a CI binding (OIDC)
  script:
    - curl -sSf "$CRUNU_INSTALL_URL" -o /tmp/crunu-install.sh
    - echo "$CRUNU_INSTALL_SHA256  /tmp/crunu-install.sh" | sha256sum -c -
    - sh /tmp/crunu-install.sh --version "$CRUNU_VERSION" --sha256 "$CRUNU_BINARY_SHA256" --user-install
    - crunu run --env web-app/staging -- npm test

Pour un jeton de production, la liaison CI (OIDC) pourrait exiger :

• project_path : kiteline/web-app
• ref : main
• ref_type : branch
• environment : production

Les modèles de jobs .crunu

Les étapes d’installation existent aussi sous forme d’un fichier de modèle avec deux jobs cachés. Vos jobs en héritent avec extends :

• .crunu installe une version figée de crunu dans before_script, vérifie le SHA-256 de l’installateur et du binaire, et affiche crunu version ;
• .crunu-oidc fait de même et ajoute id_tokens, pour les jetons dotés d’une liaison CI.

Gardez une copie du modèle dans votre dépôt : ses modifications sont ainsi relues avec votre code. Si vous l’incluez plutôt depuis un autre projet GitLab, figez ref sur un commit, pas sur une branche.

include:
  - local: ci/crunu.gitlab-ci.yml

test:
  image: node:24
  extends: .crunu
  script:
    - crunu run --env web-app/staging -- npm test

deploy:
  image: node:24
  extends: .crunu-oidc        # the production token has an OIDC rule: project_path, ref, environment
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  script:
    - crunu run --env web-app/production -- npm run deploy

Le before_script propre à un job remplace celui du modèle, car extends ne fusionne pas les listes de commandes. Rajoutez explicitement les étapes du modèle :

test:
  extends: .crunu
  before_script:
    - !reference [.crunu, before_script]
    - npm ci
  script:
    - crunu run --env web-app/staging -- npm test

Ce qui est vérifié

• La somme de contrôle de l’installateur est comparée avant son exécution. En cas d’écart, le job s’arrête et crunu n’est pas installé.
• L’installateur vérifie la somme de contrôle du binaire et l’exécute une fois avant de le mettre en place.
• Les valeurs mal formées, comme une somme de contrôle manquante ou une adresse qui n’est pas en https://, sont refusées avant tout téléchargement.

Runners et sommes de contrôle

crunu fonctionne sous Linux et macOS, en amd64 et arm64. Il n’existe pas de version Windows. La somme de contrôle du bloc CI setup concerne Linux amd64 ; pour les runners arm64, définissez des sommes de contrôle par plateforme à partir du manifest.json de la version.

Révocation

Ouvrez le jeton dans Crunu et choisissez Revoke. Sa prochaine connexion est refusée, et un job déjà en cours se termine avec ce qu’il a reçu. Si le jeton a pu fuiter, renouvelez aussi les clés des environnements qui lui étaient accordés et réémettez chez leurs fournisseurs les valeurs qu’ils contiennent.

Voir aussi

• La CI/CD dans Crunu
• GitLab CI dans la documentation
• Lier un jeton par OIDC
• Jetons de service