Le push réussissait puis le script sortait en 22 :
curl: (22) The requested URL returned error: 404
Write-Error: ... code d'erreur: 22
Deux causes cumulées, visibles seulement une fois MAX_VERSIONS dépassé.
1. Accept trop restrictif
`docker build` via buildx produit un OCI image index
(application/vnd.oci.image.index.v1+json), pas un manifest v2 plat.
delete_by_tag demandait le digest avec
`Accept: application/vnd.docker.distribution.manifest.v2+json` : le registre
répond 404 — et non 406 — quand l'Accept ne couvre pas le type stocké.
Le HEAD échouait donc sur TOUS les tags, y compris celui venait d'être
poussé. On liste maintenant les quatre media types possibles.
2. La rétention pouvait tuer un déploiement réussi
Sous `set -euo pipefail`, le curl de delete_by_tag n'était protégé par
aucun `|| true` : son code de sortie 22 se propageait et tuait le script,
transformant un push réussi en échec. Le ménage des anciennes versions est
du best-effort et ne doit jamais faire échouer le push.
Symptôme d'origine : la rétention ne s'est jamais déclenchée tant que le
nombre de tags semver est resté <= MAX_VERSIONS (5). Au 7e tag, elle a
commencé à tourner et a fait échouer le script.
Vérifié : deploy-img.ps1 publie 1.0.20, `latest` aligné sur le digest de
l'image locale (sha256:25555d9ee4bf…), rétention purgée sans erreur.
- Expand .env.example with full runtime, cache, Docker, and AI keys
- Add deployment secrets to .gitignore (docker-compose/.env,
docker/.registry.env)
- Remove VIMEO_ACCESS_TOKEN from compose files; add OAuth redirect URIs
- Load registry credentials from .registry.env in deploy-img.sh
- Fail fast if protected registry lacks auth during pre-checks
- Pass DOCKER_USERNAME/PASSWORD explicitly to WSL in deploy-img.ps1
- Remove inline collapse buttons from themes-nav.component.html