Nicolas
e2d7207237
- 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>
46 lines
3.6 KiB
Markdown
46 lines
3.6 KiB
Markdown
# 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)
|
|
|
|
1. 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.
|
|
2. 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`.
|
|
3. Ouvrir une PR "Version Packages" avec ce résultat, la relire, la merger soi-même (jamais d'auto-merge).
|
|
4. 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`
|
|
|
|
1. Forgejo → Settings → Applications → générer un token avec les scopes `write:package` + `read:package`.
|
|
2. 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).
|