Nicolas e2d7207237

CI / build-lint-test (push) Failing after 1m53s

Details

CI / build-lint-test (pull_request) Successful in 1m58s

Details

Bootstrap monorepo pnpm + migration de web-component

- Outillage complet : pnpm workspaces (catalog), Biome, TypeScript
  (project references, CommonJS/Node10), Vitest, TypeDoc (validation
  bloquante en CI), Changesets.
- Organisation des packages en catégories client/common/server.
- Migration de @lightweight-sdk/web-component (packages/client/) depuis
  l'ancien repo lightweight-sdk-web-component : code source copié à
  l'identique, aucune modification. package.json/tsconfig.json/README.md
  adaptés autour. Exclu de la validation TypeDoc stricte et de quelques
  règles Biome (formatage, noShadowRestrictedNames) puisque le code ne
  peut pas être édité pour s'y conformer - détails dans spec/packages.md.
- Workflows Forgejo Actions (.forgejo/workflows/) : ci.yml (lint, build,
  test, docs:check) et release.yml (publication sur le registre npm
  privé via Changesets).
- Script pnpm create-package <client|common|server> <nom> pour scaffolder
  les futurs packages.
- Documentation dans /spec (architecture, conventions, ci-cd, packages).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-09-18 07:10:13 +02:00

3.6 KiB

Raw Blame History

CI/CD

Workflows

Les workflows vivent dans .forgejo/workflows/ (pas .github/workflows/ — ce dernier n'est probablement pas surveillé par Forgejo Actions sur cette instance).

`ci.yml`

Déclenché sur pull_request vers main et push sur toute branche autre que main. Étapes : install (--frozen-lockfile) → pnpm lint → pnpm build → pnpm test → pnpm docs:check. Ne nécessite aucun secret (les dépendances internes entre packages passent par workspace:*, résolu localement).

`release.yml`

Déclenché sur push vers main (typiquement après le merge d'une PR "Version Packages"). Étapes : install → build → ajout dynamique d'une ligne d'authentification dans .npmrc (jamais committée) → pnpm changeset:publish.

changeset publish est idempotent par package : il republie uniquement les packages dont la version locale n'existe pas encore sur le registre. Un push sur main sans bump de version ne publie donc rien.

Flux Changesets (versioning + publication)

Pendant une PR de feature, ajouter un changeset : pnpm changeset (choisir le(s) package(s) concerné(s), le type de bump, décrire le changement). Le fichier généré dans .changeset/ est commité avec la PR.
Quand on est prêt à publier, en local : pnpm changeset version — bump les package.json concernés et génère/met à jour leurs CHANGELOG.md.
Ouvrir une PR "Version Packages" avec ce résultat, la relire, la merger soi-même (jamais d'auto-merge).
Le merge sur main déclenche release.yml, qui publie effectivement sur le registre les packages dont la version a changé.

Pas de bot automatique type changesets/action (spécifique GitHub, incertain sur Forgejo) : le flux est volontairement manuel aux étapes 1-3.

Registre npm privé Forgejo

URL : https://git.dev.kyuno.fr/api/packages/kyuno/npm/ (owner Forgejo = kyuno, indépendant du scope npm @lightweight-sdk — les deux ne sont pas liés).
.npmrc (racine, committé) : @lightweight-sdk:registry=https://git.dev.kyuno.fr/api/packages/kyuno/npm/.
Authentification : //git.dev.kyuno.fr/api/packages/kyuno/npm/:_authToken=<token> — jamais committé, injecté uniquement en CI via le secret REGISTRY_TOKEN.
Limite connue : impossible de republier un nom+version déjà existant sur le registre (Changesets gère ça nativement en forçant un bump à chaque publication).

Secret `REGISTRY_TOKEN`

Forgejo → Settings → Applications → générer un token avec les scopes write:package + read:package.
L'ajouter comme secret de repo nommé REGISTRY_TOKEN sur ce repo (lightweight-sdk) — les secrets de repo ne sont pas partagés entre repos sur cette instance ; celui de watchparty ne peut pas être réutilisé tel quel.

Troubleshooting : 404 sur un package scopé

Si pnpm changeset:publish échoue avec une 404 sur un nom de package scopé (@lightweight-sdk/...), la cause probable est le reverse proxy devant l'instance : npm encode le / d'un nom scopé en %2F, ce qu'Apache refuse par défaut. Vérifier AllowEncodedSlashes NoDecode dans le VirtualHost et nocanon sur la directive ProxyPass. Ce point n'a pas pu être vérifié depuis l'agent (config réseau propre à l'instance).

Pistes futures

git push --follow-tags après changeset publish pour taguer les releases (pas fait par défaut aujourd'hui).
Automatiser l'étape 2 du flux Changesets (PR "Version Packages" ouverte automatiquement) via un workflow workflow_dispatch ou planifié.
Protection de branche réelle sur main côté Forgejo (l'interdiction de push direct n'est aujourd'hui que conventionnelle, via CLAUDE.md).

3.6 KiB Raw Blame History