Aller au contenu

CI pour vos dépôts GitHub
sur des serveurs que nous exploitons nous-mêmes.

Chaque push et pull request lance vos tests dans une sandbox sur le matériel d’Enzonic, déjà en marche à l’arrivée du job, avec des logs en direct et un check sur GitHub. Écrivez un court .enzonic/ci.yml, ou gardez les workflows GitHub Actions que vous avez déjà.

3 000 minutes par mois gratuites. Sans carte bancaire.

Voir une configuration
$ git push origin maina41c9e2Exécution #128 réussie en 2m 18slint22stest (node 20)1m 08stest (node 22)1m 21sdeploy26spostgres:17 · healthyTous les checks sont passés4 jobs · Enzonic CI
Minutes de CI par mois
jobs à la fois
par job
de cache de dépendances

Tout ce dont un pipeline a besoin, rien à surveiller

Runners, services, caches et logs font partie du produit. Vous écrivez les étapes.

Des sandboxes déjà en marche

Chaque job reçoit sa propre sandbox sur du matériel exploité par Enzonic, démarrée à l’avance et dégelée à l’arrivée du job.

Jobs en matrice et needs

Tests sur Node 20 et 22 en même temps, puis déploiement seulement quand toutes les cellules ont réussi. Les jobs attendent les jobs dont ils ont besoin.

Services Postgres et Valkey

Lancez une vraie base de données à côté de vos tests en une seule ligne, vérifiée avant la première étape.

Caches

Gardez node_modules, les wheels pip ou les fichiers de build entre les exécutions, avec une clé construite à partir de votre lockfile.

Artefacts

Conservez les rapports de couverture, les builds et les captures d’écran, transmettez-les aux jobs suivants et téléchargez-les pendant plusieurs jours.

Logs en direct

Suivez chaque étape pendant son exécution, avec des couleurs, regroupée par étape, les étapes en échec étant ouvertes pour vous.

Checks sur GitHub

Chaque job publie un check avec des annotations sur la pull request, prêt pour la protection de branche.

Vos workflows, sans modification

Une grande partie des workflows GitHub Actions fonctionne telle quelle : matrice, services, conteneurs et actions de configuration courantes.

Planifications

Tests nocturnes ou vérifications hebdomadaires des dépendances avec une ligne cron, en UTC.

Enzica corrige les exécutions en échec

Un clic sur un job en échec : Enzica trouve la cause, pousse une branche de correction et lance le pipeline dessus.

Plus d’attente : l’exécution, ce sont vos étapes

La plus grande partie du temps de CI est consacrée au démarrage d’une machine, au clonage et au téléchargement des dépendances. Enzonic CI effectue ce travail avant l’arrivée de votre job.

  1. 01

    Les sandboxes sont dégelées, pas démarrées

    Un pool de sandboxes est démarré à l’avance. Quand un job arrive, l’une d’elles est dégelée et lui est attribuée : il n’y a donc aucune machine à démarrer.

  2. 02

    Récupérations du code depuis un miroir local

    Chaque runner garde un miroir de votre dépôt et ne récupère que ce qui a changé, au lieu de cloner depuis GitHub pour chaque job.

  3. 03

    Caches liés depuis le disque local

    Les caches de dépendances restent sur le runner et sont liés au job, au lieu d’être téléchargés et décompressés au préalable.

Chaque job montre où son temps est passé : file d’attente, sandbox, checkout, dépendances, services, cache et étapes.

Un seul fichier dans votre dépôt

Faites un commit de .enzonic/ci.yml et poussez-le. Les jobs s’exécutent dans l’ordre défini par leurs needs, les cellules de matrice en parallèle, chacune avec ses propres services, cache et artefacts.

  • le lint s’exécute en premier ; les deux cellules de test démarrent dès qu’il réussit
  • chaque cellule de test a son propre Postgres sur localhost et sur postgres:5432
  • les téléchargements npm viennent du cache indexé sur package-lock.json
  • la couverture est conservée même lorsque les tests échouent
  • le déploiement ne s’exécute que sur main, avec un secret que les logs n’affichent jamais
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  lint:
    image: node:22
    steps:
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint
    image: node:${{ matrix.node }}
    matrix:
      node: [20, 22]
    services:
      postgres:
        image: postgres:17-alpine
        env: { POSTGRES_PASSWORD: postgres }
    env:
      DATABASE_URL: postgres://postgres:postgres@postgres:5432/postgres
    cache:
      key: npm-${{ hashFiles('package-lock.json') }}
      paths: [~/.npm]
    steps:
      - run: npm ci
      - run: npm test
    artifacts:
      - name: coverage-node${{ matrix.node }}
        paths: [coverage/]
        when: always

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    steps:
      - run: npx enzonic deploy --prod
        env:
          ENZONIC_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Vous utilisez déjà GitHub Actions ?

Connectez le dépôt : vos workflows .github/workflows s’exécutent ici sans modification, tant qu’ils utilisent ce qui est listé ci-dessous. Tout le reste est refusé avec un message clair, jamais ignoré en silence.

Fonctionne telle quelle

  • actions/checkoutLe commit de l’exécution est toujours récupéré
  • actions/setup-node, setup-python, setup-go, setup-javaChoisissez l’image du job ; cache : ajoute le cache du gestionnaire de paquets
  • oven-sh/setup-bun, pnpm/action-setupImage Bun, pnpm installé
  • actions/cache (and /restore, /save)Un cache de job, restauré en premier et enregistré à la fin
  • actions/upload-artifact, download-artifactArtefacts conservés avec l’exécution et transmis entre les jobs
  • strategy.matrix, needs, if, services, containerY compris include / exclude et fail-fast

Non pris en charge

  • Autres usages : actions, actions Docker, actions composites et workflows réutilisables
  • Sorties des étapes et des jobs (steps.*.outputs, needs.*.outputs)
  • Runners Windows et macOS
  • pull_request_target
La liste complète de compatibilité

Tarifs

La CI est incluse dans votre offre Enzonic Cloud, la même qui couvre Deploy et Databases. Commencez avec l’offre gratuite ; passez à une offre supérieure si vous avez besoin de plus de minutes ou de runners plus puissants. Runners Linux uniquement.

Offres Enzonic CI
Chaque offre Cloud inclut la CI
Free
0 $US
Starter
5 $US / mois
4,17 $US par mois, facturé annuellement
Recommandé
Pro
10 $US / mois
8,33 $US par mois, facturé annuellement
Growth
19 $US / mois
15,83 $US par mois, facturé annuellement
Business
29 $US / mois
24,17 $US par mois, facturé annuellement
Minutes de CI par mois3 0005 0006 00015 00060 000
Jobs simultanés2461020
Job le plus long360 min360 min360 min480 min720 min
Cache de dépendances2 Go5 Go10 Go20 Go50 Go
Artefacts conservés90 jours90 jours90 jours180 jours400 jours
Logs conservés14 jours30 jours30 jours60 jours90 jours

Subventions pour les créateurs

Vous développez de l’open source, étudiez, enseignez ou dirigez une association ? Demandez du temps gratuit en Pro ou Business et du crédit Cloud pour Deploy et Databases.

  • Plan Pro ou Business jusqu’à un an, pour Deploy et Databases ensemble
  • Crédit Cloud ajouté à votre solde
  • Pour votre compte personnel ou toute votre équipe
  • Lue par une personne, réponse généralement en quelques jours
  • Open source
  • Étudiants
  • Associations
  • Startups
  • Enseignants
  • Hackathons

Questions

Que compte une minute de CI ?

Chaque minute commencée d’exécution d’un job est arrondie par job. Une minute sur un runner moyen compte double, et sur un grand runner quatre fois. Le temps passé en file d’attente ne compte pas, et les jobs repris de la tentative précédente lors d’une relance ne coûtent rien.

Où tournent les jobs ?

Sur des serveurs qu’Enzonic exploite lui-même, les mêmes que ceux qui font tourner Enzonic Deploy et Databases. Chaque job reçoit sa propre sandbox gVisor, avec son propre système de fichiers et son propre réseau, et ses conteneurs de services à côté. Les jobs ne partagent jamais le noyau d’une machine avec le code d’un autre client.

Pourquoi les jobs démarrent-ils si vite ?

Les sandboxes sont démarrées à l’avance et dégelées à l’arrivée d’un job, au lieu de démarrer une machine pour chaque job. Le checkout provient d’un miroir local de votre dépôt, et les caches de dépendances sont liés depuis le disque local au lieu d’être téléchargés. L’essentiel d’une exécution, ce sont vos propres étapes.

Quels systèmes d’exploitation les jobs peuvent-ils utiliser ?

Linux uniquement. Les jobs s’exécutent dans des conteneurs Linux ; les runners Windows et macOS ne sont pas disponibles.

Puis-je garder mes workflows GitHub Actions ?

Oui, à condition qu’ils s’en tiennent au sous-ensemble pris en charge : étapes run, matrix, needs, services, container, et les actions checkout, setup-node, setup-python, setup-go, setup-java, setup-bun, pnpm, cache et artifact. Un workflow qui utilise autre chose est ignoré avec un message clair, et les autres workflows s’exécutent quand même.

Que se passe-t-il avec les secrets et les pull requests depuis des forks ?

Les secrets sont chiffrés, ne parviennent qu’aux jobs qui les utilisent et sont masqués dans les logs. Les pull requests depuis des forks s’exécutent sans secrets, sans jeton GitHub et sans enregistrer de caches, ou pas du tout si vous préférez.

Comment les résultats arrivent-ils sur GitHub ?

Sous forme de checks, avec les lignes en échec annotées sur la pull request, lorsque l’application GitHub a la permission Checks. Sans elle, sous forme de statuts de commit. Les règles de protection de branche peuvent les exiger comme n’importe quel autre check.

Que se passe-t-il si une exécution échoue ?

Vous recevez un e-mail si vous le souhaitez, ainsi qu’un bouton Corriger avec Enzica sur le job en échec. Enzica lit le log et votre configuration, pousse une correction sur une nouvelle branche enzica/ci-fix et lance le pipeline dessus. Vos branches ne sont jamais modifiées : vous fusionnez la correction si elle est bonne.

Dois-je héberger mon application sur Enzonic ?

Non. La CI fonctionne avec n’importe quel dépôt GitHub. Déployez depuis un job vers l’hébergeur de votre choix, avec un secret pour le jeton, ou vers Enzonic Deploy.

Quelles images un job peut-il utiliser ?

Toute image de conteneur publique : node, python, golang, eclipse-temurin, oven/bun ou la vôtre. Les services comme postgres:17 et valkey/valkey:8 démarrent avant les étapes et sont accessibles sur localhost et par leur nom de service.

Votre prochain push peut s’exécuter ici.

Publiez aussi le résultat : Enzonic Deploy héberge vos applications web gratuitement.