Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible

Table des matières :

Build reproductible PrestaShop : ce que vous cherchez vraiment à stabiliser

En e-commerce, « intégrer en continu » ne veut pas dire « reconstruire au hasard à chaque push ». Le vrai problème, surtout sur PrestaShop (8.1 à 9.1 au moment où j’écris, côté PHP 8.1–8.5), c’est que les builds dérivent : dépendances PHP résolues différemment, artefacts front recompilés avec des timestamps variés, images Docker qui changent parce que la base :latest a bougé, etc. Résultat : vous corrigez un bug… et vous en créez un autre sans avoir touché le code. C’est la pire forme d’incident : non reproductible.

La définition utile (et vérifiable) est celle du projet Reproducible Builds : « Reproducible builds are a set of software development practices that create an independently-verifiable path from source to binary. » (reproducible-builds.org). Transposé à PrestaShop, le « binaire » n’est pas un exécutable : c’est votre artefact de déploiement (image Docker, tarball, package) + ses dépendances + ses assets compilés. L’objectif est que le même commit produise le même artefact, ou à défaut un artefact strictement équivalent (même dépendances, même hashes) et traçable.

Il faut aussi être lucide : une reproductibilité bit-for-bit d’une image Docker n’est pas triviale dès que vous faites du apt-get sur une Debian « vivante » ou du npm install sans verrou. Le bon compromis en CI PrestaShop, c’est : (1) pinning strict (base images par digest, composer.lock, lockfile JS), (2) builds hermétiques (pas de secrets persistés, pas de dépendances téléchargées « en dehors » du pipeline), (3) provenance et SBOM pour auditer ce qui a été produit. Si votre objectif est la performance, vous pouvez ensuite optimiser (BuildKit + caches) sans sacrifier la déterminisme.

Pour rendre ça concret, voici les causes de dérive les plus fréquentes en PrestaShop et le « verrou » associé (c’est souvent là que se joue la stabilité de votre intégration continue PrestaShop) :

Ce qui change « sans toucher le code »	Cause typique	Verrou pragmatique
Dépendances PHP différentes	`composer update`, `composer.lock` non commité, repos privés instables	`composer install` + `composer.lock` versionné + authentification via secret BuildKit
JS/CSS différents	`npm install`, lockfile absent, build injectant date/version	`npm ci` + lockfile (package-lock/yarn.lock/pnpm-lock) + neutraliser les timestamps si possible
Image Docker différente	base `:latest`, dépendances OS tirées « au fil de l’eau »	base par digest + stratégie OS (snapshot, image interne « golden », ou cadence de rebuild contrôlée)
Cache Symfony/PrestaShop incohérent	`var/cache` embarqué, dépendant d’ENV/modules	ne pas embarquer `var/cache` préchauffé ; warmup au runtime si nécessaire
Artefact non traçable	tags écrasés, pas de provenance	tags immuables + déploiement au digest + attestation provenance/SBOM

Dans un contexte francophone/Europe, un détail souvent sous-estimé est la traçabilité au sens audit (qui a déployé quoi, quand). Même sans exigences réglementaires spécifiques, le fait de pouvoir prouver « ce digest correspond à ce commit, sur ce workflow CI » vous évite des heures lors d’un incident (ou d’un audit client, notamment quand vous opérez des boutiques pour plusieurs marques).

BuildKit : pourquoi ce builder change la donne pour PrestaShop

BuildKit n’est pas juste « Docker build plus rapide ». Le projet le résume ainsi : « BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. » (github.com/moby/buildkit). Les mots importants pour nous : expressive (des primitives utiles à la CI) et repeatable (moins de comportements implicites). Sur une stack PrestaShop, qui mélange PHP/Composer, Node/Yarn ou npm, et des contraintes de permissions, ça évite beaucoup de bricolage.

Deux features BuildKit impactent directement la CI : les mounts et la gestion du cache. Avec RUN --mount=type=cache, vous mettez en cache le dossier Composer ou npm sans le copier dans l’image finale. Avec RUN --mount=type=secret, vous injectez un secret (token GitHub, auth.json Composer, clé privée) uniquement pendant l’étape, ce qui évite les fuites dans les layers. Et avec cache-to/cache-from (via buildx), vous pouvez partager le cache entre builds sur GitHub Actions, même avec des runners éphémères.

Sur PrestaShop, ça s’applique particulièrement bien à deux « points chauds » :

Composer : télécharger/extraire des archives peut prendre plusieurs minutes sur un runner, et c’est la première source de variance si on n’est pas strict (composer.lock, sources privées, plugins).
Build front (thème) : les node_modules sont lourds, et un mauvais ordre de COPY ou l’absence de lockfile vous fait perdre à la fois la reproductibilité et le temps de build.

Le point souvent mal compris : BuildKit n’« automatise » pas la reproductibilité. Il vous donne les outils pour la préserver tout en accélérant. Si vous utilisez composer update, une base php:8.2-fpm sans digest, ou que vous compilez des assets qui embarquent un timestamp de build, vous aurez des images différentes. BuildKit va juste produire des images différentes… plus vite.

Un bon réflexe est donc de distinguer :

déterminisme fonctionnel : mêmes dépendances, même comportement applicatif, mêmes fichiers « utiles » ;
déterminisme bit-à-bit : mêmes octets, mêmes hashes, ce qui demande souvent de neutraliser timestamps, ordre d’archivage, métadonnées de build, etc.

En CI PrestaShop, le déterminisme fonctionnel + SBOM/provenance est déjà un saut qualitatif majeur (et atteignable sans transformer votre Dockerfile en thèse).

GitHub Actions : une CI PrestaShop réaliste (jobs, matrices, artefacts)

Une CI « propre » pour PrestaShop sépare au minimum : (1) qualité de code PHP (PHPStan, Rector, lint), (2) tests (unitaires, éventuellement e2e), (3) build/push d’un artefact déployable, (4) contrôles supply chain (SBOM, vuln scan, signature). Si vous voulez industrialiser la qualité côté PHP, l’article PHPStan et Rector : industrialiser la qualité du code PHP est un bon complément.

La matrice (ex. PHP 8.2 / 8.3) est utile uniquement si vous supportez réellement plusieurs versions en prod, ou si vous développez un module compatible sur plusieurs branches PrestaShop. Sinon, vous brûlez du temps CI pour une valeur faible. À l’inverse, un job « build image » doit être mono-variant et aligné sur votre runtime réel (même PHP, mêmes extensions, mêmes settings). PrestaShop 9.1 a clarifié les compatibilités PHP et les contraintes CLI ; gardez la référence à jour : PrestaShop 9.1 : compatibilités PHP et nouveautés

Une organisation simple (et maintenable) dans GitHub Actions ressemble souvent à ceci :

lint : exécute les linters (PHP-CS-Fixer/PHPCS, YAML lint…) et échoue vite.
tests : lance les tests (unitaires et/ou intégration), produit des rapports (JUnit, coverage) en artefacts.
build : construit l’image (ou un tarball/module zip) et la pousse seulement sur branches autorisées (ex. main / tags).
security : génère SBOM/provenance, scanne l’image, et/ou signe.

Astuce pratique : sur pull_request, vous pouvez construire sans push (ou pousser dans un registry de test si vos permissions le permettent). Cela évite de polluer le registry avec des images non destinées au déploiement, tout en validant que le Dockerfile reste buildable.

Côté exécution, GitHub Actions sur runners hébergés est suffisant pour la majorité des boutiques. Vous basculez sur self-hosted runner quand vous avez : des builds multi-arch fréquents, un cache volumineux, ou des temps de build qui explosent (gros thème, dépendances privées, tests lourds). Dans ce cas, traitez ça comme une infra : durcissement, patching, rotation de secrets. La sécurité n’est pas un détail sur une CI qui construit des images déployées en production ; voir Sécurité PrestaShop : protéger API, backoffice, WAF et journalisation

Dockerfile multi-stage PrestaShop + BuildKit : exemple reproductible

Le pattern viable : multi-stage avec un stage vendor (Composer), un stage assets (Node), puis un stage runtime minimal. Sur PrestaShop, ça évite de livrer Node dans l’image finale, et ça réduit l’attaque surface. Important : on cible ici une base PHP fixe. Si vous visez la reproductibilité, préférez aussi un pinning par digest (php@sha256:...). Je mets un tag pour lisibilité, mais en prod pinnez le digest.

BuildKit s’active avec la directive # syntax= et/ou via buildx. Ensuite, vous cachez Composer et npm/yarn, et vous montez un secret pour COMPOSER_AUTH si vous avez des dépendances privées (repos Git, registry). Exemple (à adapter à votre arborescence thème et à votre stratégie d’assets) :

# syntax=docker/dockerfile:1.7

ARG PHP_VERSION=8.2

FROM composer:2.7 AS vendor
WORKDIR /app

# Maximiser le cache : uniquement les manifests au début
COPY composer.json composer.lock ./

# Cache Composer + secret auth.json (BuildKit)
RUN --mount=type=cache,target=/tmp/composer-cache \
    --mount=type=secret,id=composer_auth,target=/tmp/auth.json \
    export COMPOSER_AUTH="$(cat /tmp/auth.json)" && \
    composer install --no-dev --prefer-dist --no-interaction --no-progress \
      --classmap-authoritative \
      --cache-dir=/tmp/composer-cache

# On ne copie pas tout le projet dans ce stage : on veut un stage "vendor" stable
# (les sources applicatives seront copiées dans runtime).
# Le résultat attendu est /app/vendor + composer.lock déjà appliqué.

FROM node:20-bookworm-slim AS assets
WORKDIR /app

# Exemple : assets du thème
COPY themes/mytheme/package.json themes/mytheme/package-lock.json ./themes/mytheme/
RUN --mount=type=cache,target=/root/.npm \
    cd themes/mytheme && npm ci

COPY themes/mytheme ./themes/mytheme
# Si votre build front injecte des timestamps, regardez si votre toolchain permet
# de les neutraliser (variables d'env, config bundler) pour se rapprocher du déterminisme.
RUN cd themes/mytheme && npm run build

FROM php:${PHP_VERSION}-fpm-bookworm AS runtime
WORKDIR /var/www/html

# Extensions PHP à adapter (intl, gd, zip, pdo_mysql, etc.)
RUN apt-get update && apt-get install -y --no-install-recommends \
      libicu-dev libpng-dev libzip-dev \
    && docker-php-ext-install intl gd zip pdo_mysql \
    && rm -rf /var/lib/apt/lists/*

# Copier le code applicatif (pensez à .dockerignore pour exclure var/, vendor/, node_modules/, .git, etc.)
COPY . /var/www/html

# Injecter vendor depuis le stage Composer (sans embarquer composer)
COPY --from=vendor /app/vendor /var/www/html/vendor

# Copier les assets compilés (ou uniquement le /assets/dist)
COPY --from=assets /app/themes/mytheme /var/www/html/themes/mytheme

# Préparer les répertoires PrestaShop (permissions à ajuster selon votre runtime)
RUN mkdir -p var/cache var/logs \
 && chown -R www-data:www-data var

USER www-data

Deux limites à connaître : (1) apt-get rend l’image dépendante de l’état des mirrors Debian au moment du build (pas strictement reproductible). Pour durcir, utilisez un snapshot APT (snapshot.debian.org) ou une base déjà équipée en extensions. (2) La compilation front peut embarquer des métadonnées non déterministes (bannières, timestamps). Si votre npm run build injecte une date, neutralisez-la (variable d’environnement, plugin de bundler) ou acceptez une reproductibilité « fonctionnelle » mais pas bit-à-bit.

Enfin, pensez à l’hygiène Docker qui fait gagner autant en temps qu’en stabilité : un .dockerignore correct (exclure var/, vendor/, node_modules/, archives, exports) évite de faire varier le contexte de build et donc d’invalider vos layers sans raison.

Workflow GitHub Actions : buildx, cache GHA, tags immuables

L’erreur classique est de faire docker build sans buildx, puis de tenter de « cacher » à coup de actions/cache sur des dossiers du runner. Ça marche mal (surtout sur runners éphémères) et ça n’est pas aligné sur les layers. Utilisez docker/setup-buildx-action et docker/build-push-action avec cache-to/cache-from en type gha.

Le tagging doit être immuable. Une boutique qui pousse :prod et l’écrase à chaque build se tire une balle dans le pied : impossible de rollback propre, impossible d’audit. Tags recommandés : SHA (sha-<12chars>), et éventuellement semver pour les releases. Et gardez le digest en référence de déploiement, pas uniquement le tag.

Un autre point « qualité de vie » : activez une politique de concurrence (concurrency) sur votre workflow si vos pushes sont fréquents, pour éviter de lancer 5 builds concurrents qui se battent pour le cache (et vous font exploser le temps P95). Ce n’est pas obligatoire, mais sur une équipe qui merge vite, ça réduit les attentes inutiles.

Exemple minimal (GHCR), avec SBOM/provenance BuildKit (selon versions des actions) :

name: ci-prestashop
on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write   # utile pour signature/provenance OIDC
    steps:
      - uses: actions/checkout@v4

      - uses: docker/setup-buildx-action@v3

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/metadata-action@v5
        id: meta
        with:
          images: ghcr.io/${{ github.repository }}/prestashop
          tags: |
            type=sha,format=short

      - uses: docker/build-push-action@v6
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          build-args: |
            PHP_VERSION=8.2
          secrets: |
            composer_auth=${{ secrets.COMPOSER_AUTH_JSON }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
          sbom: true
          provenance: true

Pour aller plus loin côté CI/CD global (tests, releases, environnements), vous pouvez aussi recouper avec Développement PHP critique : architecture DDD, tests et CI/CD.

Accélérer sans casser : caches BuildKit, Composer, Node, et pièges de PrestaShop

Le cache est un accélérateur, pas une source de vérité. En CI PrestaShop, les gains sont généralement là : Composer (téléchargements) + Node (node_modules) + layers Docker. Sur un projet PrestaShop 8.2 avec thème custom et 40 dépendances PHP, on voit souvent une baisse de build de 10–12 minutes à 3–5 minutes après stabilisation des layers (copie sélective de composer.*, BuildKit cache mount, et npm ci au lieu de npm install). La métrique à suivre n’est pas « build time moyen » mais P95 (les pires builds), car ce sont eux qui bloquent vos merges.

Pour éviter les « accélérations fragiles », gardez ces règles simples :

Le cache ne doit pas changer le résultat : si la sortie diffère selon cache chaud/froid, vous avez un problème de déterminisme (pas « un problème de cache »).
Ne cachez pas var/ dans l’image : c’est un cache applicatif, pas un cache de build.
Verrouillez ce qui doit l’être : composer.lock et lockfile JS ne sont pas optionnels si vous voulez des builds stables.
Séparez le code des dépendances dans le Dockerfile (ordre des COPY) : c’est la différence entre « 3 minutes » et « 12 minutes » à chaque changement de contrôleur.

PrestaShop ajoute des pièges spécifiques : le dossier var/ grossit vite, et si vous le copiez trop tôt dans le Dockerfile, vous invalidez le cache en permanence (logs, cache Symfony/PrestaShop). En image de prod, vous ne devriez pas embarquer var/cache préchauffé « à l’aveugle » : il dépend de la config runtime, de l’environnement, et parfois de modules activés. Contentez-vous de créer les répertoires et de gérer le warmup au démarrage si nécessaire.

Mini-scenario (typique en agence) : une boutique en préprod « marche », mais en prod vous avez des erreurs intermittentes après déploiement. En analysant, vous découvrez que la CI a embarqué un var/cache construit avec une variable d’environnement différente (APP_ENV=dev ou un module activé en préprod). Le correctif n’est pas « purger le cache en prod à la main » : c’est de ne pas livrer ce cache dans l’artefact, et de standardiser le warmup sur le runtime réel.

Enfin, côté performance runtime, ne mélangez pas « cache CI » et « cache applicatif ». Redis, OPcache, Varnish ne se règlent pas dans la CI, ils se règlent dans l’infra et les config runtime. Si vous cherchez une vue systémique (stack cache côté serveur), gardez ce lien sous la main : Cache PrestaShop : Varnish, Redis, Memcached et OPcache

Supply chain : SBOM, signatures, provenance (SLSA pragmatique)

Dès que vous produisez une image Docker déployée, vous êtes dans la supply chain. SLSA résume bien l’objectif : « SLSA is a framework for improving the security of software supply chains. » (slsa.dev). Traduction concrète : être capable de répondre à « qui a produit cet artefact ? avec quel code ? quelle CI ? quelles dépendances ? ». Sans ça, vous ne faites pas de sécurité, vous faites de l’espoir.

Le trio minimal en 2026 : provenance, SBOM, signature. BuildKit/buildx + docker/build-push-action permettent de générer provenance et SBOM (ou au moins d’activer l’émission d’attestations). Pour la signature, cosign (Sigstore) est devenu un standard de facto, notamment via OIDC GitHub Actions (pas de clé privée longue durée à stocker). Exemple de politique : n’autoriser en production que des images signées par votre repo GitHub + workflow précis.

Stockez SBOM et provenance comme artefacts de build (ou attachez-les à une release) : le jour où vous devez investiguer une CVE, vous voulez un accès immédiat, pas « reconstruire pour voir ».
Reliez le déploiement à la vérification : la signature n’a de valeur que si votre CD (ou votre cluster) refuse les images non conformes. Sinon, c’est un badge.

Et n’oubliez pas la base : scanner vos images (Trivy, Grype), et surveiller les CVE côté modules critiques PrestaShop. Typiquement, si vous utilisez ps_checkout, les correctifs doivent entrer dans votre pipeline (bump dépendance, build, déploiement) en quelques heures, pas en quelques semaines. Exemple de bulletin à intégrer dans vos runbooks : CVE 2025-61922 : ps_checkout mise à jour

Déploiement contrôlé : tags, digests, rollback, compatibilité PHP/PrestaShop

Une CI propre n’a de valeur que si le déploiement consomme exactement l’artefact produit. Le pattern robuste : le workflow build pousse ghcr.io/org/app@sha256:..., et votre CD déploie le digest (Kubernetes, Nomad, Docker Swarm, ou même un docker compose strict). Le tag (ex. sha-abc1234) est un alias pratique, mais le digest est la référence immuable.

Exemple minimal côté docker-compose.yml (l’idée est le pinning au digest, pas l’outil) :

services:
  prestashop:
    image: ghcr.io/org/repo/prestashop@sha256:PUT_YOUR_DIGEST_HERE
    environment:
      - APP_ENV=prod
    volumes:
      - ps_var:/var/www/html/var
      - ps_img:/var/www/html/img
volumes:
  ps_var:
  ps_img:

Sur PrestaShop, la compatibilité PHP est un facteur de rollback. Si vous montez de PHP 8.2 à 8.3 dans l’image, vous changez aussi les extensions, le JIT/OPcache behavior, les warnings, voire certaines libs C. Gardez un mapping explicite : prestashop-9.1 + php-8.3 + extensions dans une matrice de support, et imposez-le via variables de build (ARG PHP_VERSION) + tests. L’article sur PrestaShop 9 (Symfony 6.4, API, perfs) peut servir de repère pour aligner vos choix : PrestaShop 9 : nouveautés techniques

Enfin, le rollback doit être un réflexe : un déploiement = un digest. Si l’incident survient, retour au digest précédent. La condition : ne jamais écraser un tag « stable » sans historiser, et conserver au minimum les N derniers digests (policy registry). Si vous avez déjà une démarche « runbook + monitoring » autour des pics de trafic (soldes), connectez-la à votre CI/CD : PrestaShop : performance, monitoring et runbooks

Checklist opérationnelle : les erreurs qui font perdre des heures en CI PrestaShop

Le premier piège, c’est la gestion des permissions. PrestaShop écrit dans var/ (cache/logs) et parfois dans img/, download/, upload/ selon modules. En container, décidez une fois : UID/GID (www-data ou non), et montez des volumes si nécessaire. Évitez les chmod -R 777 en build : c’est une dette de sécurité, et ça masque les vrais problèmes (umask, ownership, volumes). Corrigez plutôt l’utilisateur (USER www-data) et les chown ciblés.

Le second piège, c’est de faire des étapes qui nécessitent une base de données dans le build (install, enable modules, migrations). Une image doit être construite sans dépendre d’un service externe non mocké. Si vous avez des opérations d’init (ex. installation de modules obligatoires), faites-les en entrypoint au démarrage avec une logique idempotente (détecter si déjà installé), et logguez proprement. Quand ça casse, vous évitez la « page blanche » sans infos ; à ce sujet, gardez une méthode de diagnostic : Page vide : détection d’erreurs de rendu

Le troisième piège, c’est de confondre « build reproductible » et « build figé ». Votre pipeline doit pouvoir être rejoué, mais vous devez aussi remonter les mises à jour (dépendances, patchs OS) de manière contrôlée : job planifié (weekly), PR automatique, diff SBOM, tests, puis release. C’est le seul moyen de rester patché sans vous exposer aux surprises. Si vous devez formaliser cette gouvernance (qualité + sécurité + perfs), appuyez-vous sur une checklist sécurité actuelle : Sécurité PrestaShop 2026

Checklist courte (à relire quand « la CI part en vrille ») :

[ ] Le Dockerfile copie-t-il composer.json/composer.lock avant le reste, et utilise-t-il composer install (pas update) ?
[ ] Le thème utilise-t-il npm ci (ou l’équivalent yarn/pnpm) et un lockfile versionné ?
[ ] Le contexte Docker est-il stable (.dockerignore : var/, vendor/, node_modules/, exports, backups) ?
[ ] Les tags d’images sont-ils immuables (SHA / semver) et le déploiement est-il au digest ?
[ ] Les secrets (auth Composer, tokens) passent-ils via --mount=type=secret/secrets CI, jamais copiés dans l’image ?
[ ] Avez-vous une routine de mise à jour « contrôlée » (PR planifiée) plutôt qu’un patching opportuniste en prod ?