Johan LEROY
3ca4839a02
Les CI de deux push rapprochés peuvent finir dans le désordre. deploy.yml faisait alors reset --hard sur un GITHUB_SHA plus ancien que celui déjà déployé, et le groupe concurrency deploy-<branche> ne garde qu'un job en attente : un troisième arrivé annulait le précédent, qui n'était jamais déployé. - un commit qui précède celui déjà déployé est ignoré, avec une annotation dans le run ; - le groupe concurrency cède la place à un flock posé dans le clone de la VM, tenu du fetch jusqu'à la sonde de santé : les déploiements passent un par un, aucun n'est annulé ; - les trois étapes n'en font plus qu'une, le verrou tombant avec le shell qui l'a posé ; les journaux restent découpés par ::group::. ADR 0014 et 50-cicd.md décrivent les deux gardes.
69 lines
3.0 KiB
YAML
69 lines
3.0 KiB
YAML
# Pourquoi : le runner tourne sur la VM ENI, adresse privée que les runners hébergés par GitHub
|
|
# ne joignent pas, et travaille dans un dossier stable par environnement plutôt que dans son
|
|
# espace de travail : `.env`, certificats et volumes y survivent d'un déploiement à l'autre.
|
|
# Pourquoi : appelé par ci.yml une fois « CI ok » vert, jamais directement par un push, et il
|
|
# déploie `GITHUB_SHA`, le commit testé, pas la pointe de branche du moment (ADR 0014).
|
|
# Piège : jamais de déclencheur `pull_request` ici. Sur un dépôt public, une PR de fork
|
|
# exécuterait son code sur la machine de production (ADR 0009) - job deploy.
|
|
# Piège : les CI de deux push finissent parfois dans le désordre. Un commit qui précède celui déjà
|
|
# déployé est ignoré, et le verrou est un `flock` sur la VM plutôt qu'un groupe `concurrency` :
|
|
# GitHub n'y garde qu'un job en attente, et le suivant l'évince sans bruit.
|
|
|
|
name: Déploiement
|
|
|
|
on:
|
|
workflow_call:
|
|
workflow_dispatch:
|
|
|
|
permissions:
|
|
contents: read
|
|
|
|
jobs:
|
|
deploy:
|
|
name: Déploie sur la VM
|
|
runs-on: [self-hosted, linux, eni-g3]
|
|
timeout-minutes: 30
|
|
environment:
|
|
name: ${{ github.ref_name == 'main' && 'prod' || 'rec' }}
|
|
url: ${{ github.ref_name == 'main' && 'https://enervision.local' || 'https://rec.enervision.local:8443' }}
|
|
env:
|
|
ENVIRONNEMENT: ${{ github.ref_name == 'main' && 'prod' || 'rec' }}
|
|
PORT_HTTPS: ${{ github.ref_name == 'main' && '443' || '8443' }}
|
|
steps:
|
|
# Un seul step : le verrou tombe avec le shell qui l'a posé.
|
|
- name: Déploie le commit testé, sans jamais reculer
|
|
run: |
|
|
cd "/srv/enervision/${ENVIRONNEMENT}"
|
|
exec 9>"$(git rev-parse --git-dir)/verrou-deploiement"
|
|
flock 9
|
|
|
|
echo "::group::Aligne le dossier de l'environnement sur le commit testé"
|
|
git fetch --quiet origin "${GITHUB_REF_NAME}"
|
|
deploye="$(git rev-parse HEAD)"
|
|
if [ "$deploye" != "$GITHUB_SHA" ] && git merge-base --is-ancestor "$GITHUB_SHA" "$deploye"; then
|
|
echo "::notice::${GITHUB_SHA:0:7} précède le commit déjà déployé (${deploye:0:7}) : rien à déployer."
|
|
exit 0
|
|
fi
|
|
git checkout --quiet "${GITHUB_REF_NAME}"
|
|
git reset --quiet --hard "${GITHUB_SHA}"
|
|
git log -1 --format='%h %s'
|
|
echo "::endgroup::"
|
|
|
|
echo "::group::Reconstruit et redémarre la stack"
|
|
make stack-up
|
|
echo "::endgroup::"
|
|
|
|
echo "::group::Attend que l'API réponde derrière le proxy"
|
|
for _ in $(seq 1 36); do
|
|
if curl --fail --silent --insecure "https://localhost:${PORT_HTTPS}/api/v1/health/ready"; then
|
|
exit 0
|
|
fi
|
|
sleep 5
|
|
done
|
|
echo "::endgroup::"
|
|
echo "L'API ne répond pas après 3 minutes" >&2
|
|
compose="docker compose -f docker-compose.yml -f docker-compose.prod.yml"
|
|
$compose ps
|
|
$compose logs --tail=50 backend proxy
|
|
exit 1
|