10.07 — `tests-workers` : pas de CI GitHub, déploiement Vercel auto#

Le seul dépôt de l’écosystème sans workflow GitHub Actions. Tout passe par Vercel.

Le contenu du `.github/`#

tests-workers/
└── (aucun .github/ — pas de workflows)

Pas de ci.yml. Pas de deploy.yml. Pas d’action GitHub.

`vercel.json`#

{
  "version": 2,
  "buildCommand": "echo 'No build required'",
  "outputDirectory": ".",
  "framework": null
}

Vercel détecte le projet comme TypeScript Edge Functions, build à la volée (transpile TS au runtime).

`package.json#scripts`#

{
  "scripts": {
    "vercel-build": "echo 'Build skipped'"
  }
}

vercel-build hook : echo no-op.
Vercel ne tente pas de build.

Le déploiement (manuel)#

Documenté dans le README :

→ pnpm install
→ vercel env add API_SECRET
→ vercel env add UPSTASH_REDIS_REST_URL
→ vercel env add UPSTASH_REDIS_REST_TOKEN
→ vercel deploy

C’est tout. Quatre commandes, exécutées par l’auteur depuis sa machine.

Pourquoi pas de CI GitHub#

Raison	Détail
Vercel auto-deploy depuis le repo	Vercel peut être configuré pour deploy automatiquement à chaque push GitHub.
Pas de tests dynamiques	Le code n’est pas à risque, a été testé manuellement, et ne sera plus mis à jour. C’est un projet terminé.
Pas de checks statiques	Aucun test statique automatisé non plus. Tout a été testé manuellement. Des anomalies sur ce composant seraient rapidement détectées via les tests e2e et sont facilement isolables et reproductibles. La plupart du temps, par expérience, les problèmes viennent plutôt d’Upstash qui décide de kill l’instance Redis sans raison par exemple.

Auto-deploy Vercel#

Vercel offre une intégration GitHub native :

Connecter le repo GitHub à un projet Vercel.
Vercel deploy chaque push main → production.
Vercel deploy chaque PR → preview URL.

Le vercel.json et les env vars sont configurés une fois côté dashboard Vercel. Plus rien à faire ensuite.

URL de production#

https://tests-workers.vercel.app

Avec les endpoints :

https://tests-workers.vercel.app/api/otp?_user=<u>
https://tests-workers.vercel.app/api/otp-history
https://tests-workers.vercel.app/api/corsicadex?id=<n>

Cf. ../06-tests-workers/

Contraste avec les autres déploiements#

Dépôt	Hébergement	Trigger deploy	YAML CI
`igoristan`	GitHub Pages	push main	`deploy.yml`
`ocarina-holy-book`	GitHub Pages	push main	`deploy.yml`
`tests-workers`	Vercel	push main (auto Vercel)	aucun
`ocarina` (artefact Allure)	GitHub Pages	push main + action composite	`main_ci.yml` + action composite

Trois patterns différents. tests-workers est le seul à déléguer entièrement le deploy à un service tiers.

Avantage / inconvénient#

Le projet accepte le vendor lock-in pour la simplicité. C’est cohérent avec un projet qui doit être déployable en 30 secondes et qui de toute manière est tout petit et pourrait rapidement être migré en cas de problème.

La licence ISC#

tests-workers est en ISC (et pas MIT comme les autres). Provient du scaffold Vercel CLI qui génère ISC par défaut. L’auteur n’a même pas regardé.

Note : ISC ≈ MIT (les deux sont des licences permissives à 1 paragraphe). Aucune différence pratique pour les contributeurs.

Sécurité#

API_SECRET est :

Stocké dans les variables d’environnement côté Vercel (dashboard).
Jamais commit dans le repo.
Lu au cold-start du Worker via process.env.API_SECRET.

10.07 — tests-workers : pas de CI GitHub, déploiement Vercel auto#

Le contenu du .github/#

vercel.json#

package.json#scripts#