[DnzzL]

Summary

Un commentaire /deploy-staging sur une PR publie en :staging l'image frontend déjà construite par la CI pour cette PR. Watchtower la redéploie sur https://website-staging.services.dataforgood.fr.

commentaire "/deploy-staging" sur une PR
  resolve
    auteur sans droit d'écriture  -> ignoré
    PR issue d'un fork            -> échec, commentaire
    image <n°>-merge-<sha> absente -> échec, commentaire
    commentaire "en attente d'approbation : <run>"
  deploy  (environment staging : approbation requise)
    retague l'image en :staging
    commentaire "déployé <sha>" ou "échec"

• Le workflow est toujours lu depuis main : une PR ne peut pas retirer ces garde-fous.
• Le code de la PR n'est jamais exécuté. Le workflow retague une image existante, sans reconstruire.
• Une nouvelle demande remplace celle encore en attente d'approbation.

Evidence

• Avant : aucun moyen de mettre une PR en staging ; website-staging répond 502 Bad Gateway.
• Après : actionlint passe sans alerte. Le workflow ne peut pas tourner avant le merge : issue_comment lit la version de main. Premier test réel : /deploy-staging sur Supprimer les erreurs de console restantes du frontend #404.

Merge Danger

Door: two-way

Supprimer le fichier désactive tout. L'environment staging (approbateur : @DnzzL, branche autorisée : main) est déjà créé dans les réglages du dépôt.

Blast Radius: staging

Ne touche ni build-and-push.yml ni l'image :latest de la prod. Le staging tourne sur le cluster de production : 1 replica, et il lit le Strapi configuré pour la stack staging, en lecture seule.