chore(i18n): refresh fr translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
34b3686802
commit
a980301258
@ -1,28 +1,28 @@
|
||||
---
|
||||
read_when:
|
||||
- Vous souhaitez servir des modèles depuis votre propre machine GPU
|
||||
- Vous configurez LM Studio ou un proxy compatible OpenAI
|
||||
- Vous avez besoin des conseils les plus sûrs pour les modèles locaux
|
||||
- Vous souhaitez servir des modèles depuis votre propre machine GPU.
|
||||
- Vous configurez LM Studio ou un proxy compatible OpenAI.
|
||||
- Vous avez besoin des conseils les plus sûrs pour les modèles locaux.
|
||||
summary: Exécutez OpenClaw sur des LLM locaux (LM Studio, vLLM, LiteLLM, points de terminaison OpenAI personnalisés)
|
||||
title: Modèles locaux
|
||||
x-i18n:
|
||||
generated_at: "2026-04-13T08:50:46Z"
|
||||
generated_at: "2026-04-14T06:55:40Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 3ecb61b3e6e34d3666f9b688cd694d92c5fb211cf8c420fa876f7ccf5789154a
|
||||
source_hash: 1544c522357ba4b18dfa6d05ea8d60c7c6262281b53863d9aee7002464703ca7
|
||||
source_path: gateway/local-models.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Modèles locaux
|
||||
|
||||
Le local est possible, mais OpenClaw attend un grand contexte ainsi que de solides défenses contre les injections de prompt. Les petites cartes tronquent le contexte et affaiblissent la sécurité. Visez haut : **≥2 Mac Studios au maximum de leur capacité ou une machine GPU équivalente (~30 k$+)**. Un seul GPU de **24 Go** ne fonctionne que pour des prompts plus légers avec une latence plus élevée. Utilisez la **variante de modèle la plus grande / pleine taille que vous pouvez exécuter** ; les checkpoints fortement quantifiés ou « small » augmentent le risque d’injection de prompt (voir [Sécurité](/fr/gateway/security)).
|
||||
Le local est possible, mais OpenClaw s’attend à un contexte large ainsi qu’à de solides défenses contre l’injection de prompt. Les petites cartes tronquent le contexte et affaiblissent la sécurité. Visez haut : **≥2 Mac Studios au maximum de leur capacité ou une machine GPU équivalente (~30 k$+)**. Un seul GPU de **24 Go** ne fonctionne que pour des prompts plus légers avec une latence plus élevée. Utilisez la **variante de modèle la plus grande / de taille complète que vous pouvez exécuter** ; les checkpoints fortement quantifiés ou « small » augmentent le risque d’injection de prompt (voir [Sécurité](/fr/gateway/security)).
|
||||
|
||||
Si vous souhaitez la configuration locale avec le moins de friction, commencez par [LM Studio](/fr/providers/lmstudio) ou [Ollama](/fr/providers/ollama) et `openclaw onboard`. Cette page est le guide prescriptif pour les piles locales haut de gamme et les serveurs locaux personnalisés compatibles OpenAI.
|
||||
Si vous voulez la configuration locale la plus simple, commencez par [LM Studio](/fr/providers/lmstudio) ou [Ollama](/fr/providers/ollama) et `openclaw onboard`. Cette page est le guide orienté recommandations pour les piles locales plus haut de gamme et les serveurs locaux personnalisés compatibles OpenAI.
|
||||
|
||||
## Recommandé : LM Studio + grand modèle local (API Responses)
|
||||
|
||||
La meilleure pile locale actuelle. Chargez un grand modèle dans LM Studio (par exemple, une version pleine taille de Qwen, DeepSeek ou Llama), activez le serveur local (par défaut `http://127.0.0.1:1234`), et utilisez l’API Responses pour garder le raisonnement séparé du texte final.
|
||||
La meilleure pile locale actuelle. Chargez un grand modèle dans LM Studio (par exemple, une version taille complète de Qwen, DeepSeek ou Llama), activez le serveur local (par défaut `http://127.0.0.1:1234`), et utilisez l’API Responses pour séparer le raisonnement du texte final.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -62,13 +62,13 @@ La meilleure pile locale actuelle. Chargez un grand modèle dans LM Studio (par
|
||||
**Liste de configuration**
|
||||
|
||||
- Installez LM Studio : [https://lmstudio.ai](https://lmstudio.ai)
|
||||
- Dans LM Studio, téléchargez la **plus grande version de modèle disponible** (évitez les variantes « small » / fortement quantifiées), démarrez le serveur, confirmez que `http://127.0.0.1:1234/v1/models` l’affiche.
|
||||
- Remplacez `my-local-model` par l’identifiant réel du modèle affiché dans LM Studio.
|
||||
- Dans LM Studio, téléchargez la **plus grande version de modèle disponible** (évitez les variantes « small » / fortement quantifiées), démarrez le serveur, et confirmez que `http://127.0.0.1:1234/v1/models` le liste.
|
||||
- Remplacez `my-local-model` par l’ID réel du modèle affiché dans LM Studio.
|
||||
- Gardez le modèle chargé ; le chargement à froid ajoute de la latence au démarrage.
|
||||
- Ajustez `contextWindow`/`maxTokens` si votre version de LM Studio diffère.
|
||||
- Ajustez `contextWindow` / `maxTokens` si votre version de LM Studio diffère.
|
||||
- Pour WhatsApp, restez sur l’API Responses afin que seul le texte final soit envoyé.
|
||||
|
||||
Gardez les modèles hébergés configurés même lorsque vous exécutez du local ; utilisez `models.mode: "merge"` afin que les solutions de repli restent disponibles.
|
||||
Gardez les modèles hébergés configurés même lorsque vous exécutez du local ; utilisez `models.mode: "merge"` pour que des solutions de repli restent disponibles.
|
||||
|
||||
### Configuration hybride : primaire hébergé, repli local
|
||||
|
||||
@ -113,16 +113,16 @@ Gardez les modèles hébergés configurés même lorsque vous exécutez du local
|
||||
|
||||
### Priorité au local avec filet de sécurité hébergé
|
||||
|
||||
Inversez l’ordre du primaire et du repli ; conservez le même bloc providers et `models.mode: "merge"` afin de pouvoir basculer vers Sonnet ou Opus lorsque la machine locale est indisponible.
|
||||
Inversez l’ordre du primaire et du repli ; conservez le même bloc `providers` et `models.mode: "merge"` afin de pouvoir basculer vers Sonnet ou Opus lorsque la machine locale est indisponible.
|
||||
|
||||
### Hébergement régional / routage des données
|
||||
|
||||
- Des variantes MiniMax/Kimi/GLM hébergées existent aussi sur OpenRouter avec des points de terminaison fixés par région (par exemple, hébergés aux États-Unis). Choisissez la variante régionale là-bas pour conserver le trafic dans la juridiction souhaitée tout en utilisant `models.mode: "merge"` pour les replis Anthropic/OpenAI.
|
||||
- Le tout-local reste la voie la plus forte pour la confidentialité ; le routage régional hébergé est l’option intermédiaire lorsque vous avez besoin de fonctionnalités du fournisseur tout en voulant garder le contrôle sur le flux de données.
|
||||
- Des variantes MiniMax/Kimi/GLM hébergées existent aussi sur OpenRouter avec des points de terminaison épinglés par région (par ex. hébergés aux États-Unis). Choisissez la variante régionale correspondante pour garder le trafic dans la juridiction de votre choix tout en utilisant `models.mode: "merge"` pour les replis Anthropic/OpenAI.
|
||||
- Le tout-local reste la voie la plus forte pour la confidentialité ; le routage régional hébergé constitue un compromis lorsque vous avez besoin de fonctionnalités de fournisseur tout en voulant garder le contrôle sur le flux de données.
|
||||
|
||||
## Autres proxys locaux compatibles OpenAI
|
||||
|
||||
vLLM, LiteLLM, OAI-proxy ou des passerelles personnalisées fonctionnent s’ils exposent un point de terminaison `/v1` de style OpenAI. Remplacez le bloc provider ci-dessus par votre point de terminaison et l’identifiant de modèle :
|
||||
vLLM, LiteLLM, OAI-proxy ou des passerelles personnalisées fonctionnent s’ils exposent un point de terminaison `/v1` de style OpenAI. Remplacez le bloc provider ci-dessus par votre point de terminaison et l’ID de votre modèle :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -150,25 +150,42 @@ vLLM, LiteLLM, OAI-proxy ou des passerelles personnalisées fonctionnent s’ils
|
||||
}
|
||||
```
|
||||
|
||||
Conservez `models.mode: "merge"` afin que les modèles hébergés restent disponibles en repli.
|
||||
Conservez `models.mode: "merge"` pour que les modèles hébergés restent disponibles comme solutions de repli.
|
||||
|
||||
Remarque de comportement pour les backends `/v1` locaux / proxifiés :
|
||||
|
||||
- OpenClaw les traite comme des routes compatibles OpenAI de type proxy, et non comme des points de terminaison OpenAI natifs
|
||||
- la mise en forme des requêtes propre à OpenAI natif ne s’applique pas ici : pas de `service_tier`, pas de `store` pour Responses, pas de mise en forme de charge utile de compatibilité de raisonnement OpenAI, et pas d’indices de cache de prompt
|
||||
- les en-têtes d’attribution OpenClaw cachés (`originator`, `version`, `User-Agent`) ne sont pas injectés sur ces URL de proxy personnalisées
|
||||
- OpenClaw les traite comme des routes de proxy compatibles OpenAI, et non comme des points de terminaison OpenAI natifs
|
||||
- le façonnage de requête propre à OpenAI natif ne s’applique pas ici : pas de
|
||||
`service_tier`, pas de `store` Responses, pas de façonnage de payload de compatibilité de raisonnement OpenAI,
|
||||
et pas d’indices de cache de prompt
|
||||
- les en-têtes d’attribution OpenClaw masqués (`originator`, `version`, `User-Agent`)
|
||||
ne sont pas injectés sur ces URL de proxy personnalisées
|
||||
|
||||
Notes de compatibilité pour les backends compatibles OpenAI plus stricts :
|
||||
Remarques de compatibilité pour les backends compatibles OpenAI plus stricts :
|
||||
|
||||
- Certains serveurs n’acceptent que `messages[].content` sous forme de chaîne sur Chat Completions, et non des tableaux structurés de parties de contenu. Définissez `models.providers.<provider>.models[].compat.requiresStringContent: true` pour ces points de terminaison.
|
||||
- Certains backends locaux plus petits ou plus stricts sont instables avec la forme complète des prompts du runtime d’agent d’OpenClaw, en particulier lorsque des schémas d’outils sont inclus. Si le backend fonctionne pour de petits appels directs `/v1/chat/completions` mais échoue sur des tours d’agent OpenClaw normaux, essayez d’abord `models.providers.<provider>.models[].compat.supportsTools: false`.
|
||||
- Si le backend échoue encore uniquement sur des exécutions OpenClaw plus volumineuses, le problème restant est généralement une limite en amont du modèle/serveur ou un bug du backend, et non de la couche de transport d’OpenClaw.
|
||||
- Certains serveurs n’acceptent que `messages[].content` sous forme de chaîne sur Chat Completions, et non
|
||||
des tableaux structurés de parties de contenu. Définissez
|
||||
`models.providers.<provider>.models[].compat.requiresStringContent: true` pour
|
||||
ces points de terminaison.
|
||||
- Certains backends locaux plus petits ou plus stricts sont instables avec la forme complète
|
||||
de prompt du runtime d’agent d’OpenClaw, en particulier lorsque des schémas d’outils sont inclus. Si le
|
||||
backend fonctionne pour de petits appels directs à `/v1/chat/completions` mais échoue sur des tours d’agent
|
||||
OpenClaw normaux, essayez d’abord
|
||||
`models.providers.<provider>.models[].compat.supportsTools: false`.
|
||||
- Si le backend échoue toujours uniquement sur des exécutions OpenClaw plus volumineuses, le problème restant
|
||||
provient généralement de la capacité du modèle/serveur en amont ou d’un bug du backend, et non de la
|
||||
couche de transport d’OpenClaw.
|
||||
|
||||
## Dépannage
|
||||
|
||||
- Gateway peut joindre le proxy ? `curl http://127.0.0.1:1234/v1/models`.
|
||||
- La Gateway peut atteindre le proxy ? `curl http://127.0.0.1:1234/v1/models`.
|
||||
- Modèle LM Studio déchargé ? Rechargez-le ; le démarrage à froid est une cause fréquente de « blocage ».
|
||||
- OpenClaw avertit lorsque la fenêtre de contexte détectée est inférieure à **32k** et bloque en dessous de **16k**. Si vous rencontrez ce précontrôle, augmentez la limite de contexte du serveur/modèle ou choisissez un modèle plus grand.
|
||||
- Erreurs de contexte ? Réduisez `contextWindow` ou augmentez la limite de votre serveur.
|
||||
- Le serveur compatible OpenAI renvoie `messages[].content ... expected a string` ? Ajoutez `compat.requiresStringContent: true` sur cette entrée de modèle.
|
||||
- Les petits appels directs `/v1/chat/completions` fonctionnent, mais `openclaw infer model run` échoue sur Gemma ou un autre modèle local ? Désactivez d’abord les schémas d’outils avec `compat.supportsTools: false`, puis retestez. Si le serveur plante encore uniquement sur de plus grands prompts OpenClaw, traitez cela comme une limite du serveur/modèle en amont.
|
||||
- Sécurité : les modèles locaux contournent les filtres côté fournisseur ; gardez des agents ciblés et Compaction activé afin de limiter le rayon d’impact des injections de prompt.
|
||||
- Le serveur compatible OpenAI renvoie `messages[].content ... expected a string` ?
|
||||
Ajoutez `compat.requiresStringContent: true` sur cette entrée de modèle.
|
||||
- De petits appels directs à `/v1/chat/completions` fonctionnent, mais `openclaw infer model run`
|
||||
échoue sur Gemma ou un autre modèle local ? Désactivez d’abord les schémas d’outils avec
|
||||
`compat.supportsTools: false`, puis retestez. Si le serveur plante toujours uniquement
|
||||
sur des prompts OpenClaw plus volumineux, considérez cela comme une limitation du serveur/modèle en amont.
|
||||
- Sécurité : les modèles locaux contournent les filtres côté fournisseur ; gardez des agents limités dans leur portée et Compaction activé afin de limiter le rayon d’impact des injections de prompt.
|
||||
|
||||
@ -1,14 +1,14 @@
|
||||
---
|
||||
read_when:
|
||||
- Recherche des définitions des canaux de publication publics
|
||||
- Recherche de la dénomination des versions et de la cadence
|
||||
summary: Canaux de publication publics, dénomination des versions et cadence
|
||||
- À la recherche des définitions des canaux de publication publics
|
||||
- À la recherche du nommage des versions et de la cadence
|
||||
summary: Canaux de publication publics, nommage des versions et cadence
|
||||
title: Politique de publication
|
||||
x-i18n:
|
||||
generated_at: "2026-04-14T02:08:38Z"
|
||||
generated_at: "2026-04-14T06:55:41Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: fdc32839447205d74ba7a20a45fbac8e13b199174b442a1e260e3fce056c63da
|
||||
source_hash: 3eaf9f1786b8c9fd4f5a9c657b623cb69d1a485958e1a9b8f108511839b63587
|
||||
source_path: reference/RELEASING.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,114 +17,115 @@ x-i18n:
|
||||
|
||||
OpenClaw a trois canaux de publication publics :
|
||||
|
||||
- stable : des publications taguées qui publient vers npm `beta` par défaut, ou vers npm `latest` sur demande explicite
|
||||
- beta : des tags de prépublication qui publient vers npm `beta`
|
||||
- stable : versions taguées qui publient sur npm `beta` par défaut, ou sur npm `latest` lorsqu’elles sont explicitement demandées
|
||||
- beta : tags de préversion qui publient sur npm `beta`
|
||||
- dev : la tête mobile de `main`
|
||||
|
||||
## Dénomination des versions
|
||||
## Nommage des versions
|
||||
|
||||
- Version de publication stable : `YYYY.M.D`
|
||||
- Tag Git : `vYYYY.M.D`
|
||||
- Version de publication corrective stable : `YYYY.M.D-N`
|
||||
- Version de publication de correction stable : `YYYY.M.D-N`
|
||||
- Tag Git : `vYYYY.M.D-N`
|
||||
- Version de prépublication beta : `YYYY.M.D-beta.N`
|
||||
- Version de préversion beta : `YYYY.M.D-beta.N`
|
||||
- Tag Git : `vYYYY.M.D-beta.N`
|
||||
- Ne remplissez pas le mois ou le jour avec des zéros
|
||||
- `latest` signifie la publication npm stable promue actuelle
|
||||
- N’ajoutez pas de zéro de remplissage au mois ou au jour
|
||||
- `latest` signifie la version npm stable promue actuelle
|
||||
- `beta` signifie la cible d’installation beta actuelle
|
||||
- Les publications stables et les publications correctives stables publient vers npm `beta` par défaut ; les opérateurs de publication peuvent cibler explicitement `latest`, ou promouvoir plus tard une build beta validée
|
||||
- Chaque publication OpenClaw livre ensemble le package npm et l’app macOS
|
||||
- Les versions stables et les versions de correction stable publient sur npm `beta` par défaut ; les opérateurs de publication peuvent cibler `latest` explicitement, ou promouvoir plus tard une build beta validée
|
||||
- Chaque version d’OpenClaw livre le package npm et l’app macOS ensemble
|
||||
|
||||
## Cadence de publication
|
||||
|
||||
- Les publications passent d’abord par beta
|
||||
- Stable ne suit qu’après validation de la dernière beta
|
||||
- Stable ne suit qu’une fois la dernière beta validée
|
||||
- La procédure de publication détaillée, les approbations, les identifiants et les notes de récupération sont réservés aux mainteneurs
|
||||
|
||||
## Vérifications préalables à la publication
|
||||
|
||||
- Exécutez `pnpm build && pnpm ui:build` avant `pnpm release:check` afin que les artefacts de publication `dist/*` attendus et le bundle de l’interface utilisateur de Control existent pour l’étape de validation du pack
|
||||
- Exécutez `pnpm build && pnpm ui:build` avant `pnpm release:check` afin que les artefacts de publication `dist/*` attendus et le bundle de l’UI de contrôle existent pour l’étape de validation du pack
|
||||
- Exécutez `pnpm release:check` avant chaque publication taguée
|
||||
- Les vérifications de publication s’exécutent désormais dans un workflow manuel séparé :
|
||||
- Les vérifications de publication s’exécutent maintenant dans un workflow manuel séparé :
|
||||
`OpenClaw Release Checks`
|
||||
- Cette séparation est intentionnelle : garder le vrai chemin de publication npm court, déterministe et centré sur les artefacts, tandis que les vérifications live plus lentes restent dans leur propre canal afin de ne pas ralentir ni bloquer la publication
|
||||
- Les vérifications de publication doivent être déclenchées depuis la référence de workflow `main` afin que la logique du workflow et les secrets restent canoniques
|
||||
- Ce workflow accepte soit un tag de publication existant, soit le SHA de commit `main` complet actuel sur 40 caractères
|
||||
- En mode commit-SHA, il n’accepte que le HEAD actuel de `origin/main` ; utilisez un tag de publication pour des commits de publication plus anciens
|
||||
- La vérification préalable en mode validation uniquement de `OpenClaw NPM Release` accepte aussi le SHA de commit `main` complet actuel sur 40 caractères sans exiger de tag poussé
|
||||
- Ce chemin SHA est uniquement destiné à la validation et ne peut pas être promu en véritable publication
|
||||
- En mode SHA, le workflow synthétise `v<package.json version>` uniquement pour la vérification des métadonnées du package ; la véritable publication exige toujours un vrai tag de publication
|
||||
- Cette séparation est intentionnelle : elle garde le vrai chemin de publication npm court, déterministe et centré sur les artefacts, tandis que les vérifications live plus lentes restent dans leur propre canal pour ne pas retarder ou bloquer la publication
|
||||
- Les vérifications de publication doivent être déclenchées depuis la ref de workflow `main` afin que la logique du workflow et les secrets restent canoniques
|
||||
- Ce workflow accepte soit un tag de publication existant, soit le SHA de commit `main` complet actuel à 40 caractères
|
||||
- En mode SHA de commit, il n’accepte que le HEAD actuel de `origin/main` ; utilisez un tag de publication pour les anciens commits de publication
|
||||
- La pré-vérification en validation seule de `OpenClaw NPM Release` accepte également le SHA de commit `main` complet actuel à 40 caractères sans nécessiter de tag poussé
|
||||
- Ce chemin SHA est réservé à la validation et ne peut pas être promu en véritable publication
|
||||
- En mode SHA, le workflow synthétise `v<package.json version>` uniquement pour la vérification des métadonnées du package ; la vraie publication exige toujours un vrai tag de publication
|
||||
- Les deux workflows gardent le vrai chemin de publication et de promotion sur des runners hébergés par GitHub, tandis que le chemin de validation non mutatif peut utiliser les runners Linux Blacksmith plus grands
|
||||
- Ce workflow exécute
|
||||
`OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
|
||||
en utilisant à la fois les secrets de workflow `OPENAI_API_KEY` et `ANTHROPIC_API_KEY`
|
||||
- La vérification préalable de la publication npm n’attend plus le canal séparé des vérifications de publication
|
||||
- La pré-vérification de publication npm n’attend plus le canal séparé des vérifications de publication
|
||||
- Exécutez `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
|
||||
(ou le tag beta/correctif correspondant) avant approbation
|
||||
(ou le tag beta/correction correspondant) avant l’approbation
|
||||
- Après la publication npm, exécutez
|
||||
`node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
|
||||
(ou la version beta/corrective correspondante) pour vérifier le chemin d’installation du registre publié dans un préfixe temporaire vierge
|
||||
- L’automatisation de publication des mainteneurs utilise désormais le modèle vérification-préalable-puis-promotion :
|
||||
- la véritable publication npm doit réussir un `preflight_run_id` npm valide
|
||||
(ou la version beta/correction correspondante) pour vérifier le chemin d’installation du registre publié dans un préfixe temporaire frais
|
||||
- L’automatisation de publication des mainteneurs utilise désormais le modèle pré-vérification puis promotion :
|
||||
- la vraie publication npm doit réussir avec un `preflight_run_id` de pré-vérification réussi
|
||||
- les publications npm stables ciblent `beta` par défaut
|
||||
- une publication npm stable peut cibler explicitement `latest` via une entrée de workflow
|
||||
- la promotion npm stable de `beta` vers `latest` reste disponible comme mode manuel explicite dans le workflow approuvé `OpenClaw NPM Release`
|
||||
- les publications stables directes peuvent aussi exécuter un mode explicite de synchronisation des dist-tags qui pointe à la fois `latest` et `beta` vers la version stable déjà publiée
|
||||
- ces modes de dist-tag nécessitent toujours un `NPM_TOKEN` valide dans l’environnement `npm-release`, car la gestion des `npm dist-tag` est séparée de la publication approuvée
|
||||
- `macOS Release` public est uniquement destiné à la validation
|
||||
- la véritable publication privée mac doit réussir des `preflight_run_id` et `validate_run_id` privés mac valides
|
||||
- les vrais chemins de publication promeuvent les artefacts préparés au lieu de les reconstruire à nouveau
|
||||
- Pour les publications correctives stables comme `YYYY.M.D-N`, le vérificateur post-publication contrôle aussi le même chemin de mise à niveau en préfixe temporaire de `YYYY.M.D` vers `YYYY.M.D-N` afin que les correctifs de publication ne puissent pas laisser silencieusement d’anciennes installations globales sur la charge utile stable de base
|
||||
- La vérification préalable de publication npm échoue en mode fermé à moins que le tarball inclue à la fois `dist/control-ui/index.html` et une charge utile non vide `dist/control-ui/assets/` afin d’éviter d’expédier à nouveau un tableau de bord navigateur vide
|
||||
- Si le travail de publication a touché à la planification CI, aux manifestes de temporisation des extensions ou aux matrices de test des extensions, régénérez et examinez les sorties de matrice de workflow `checks-node-extensions` détenues par le planificateur depuis `.github/workflows/ci.yml` avant approbation afin que les notes de publication ne décrivent pas une disposition CI obsolète
|
||||
- L’état de préparation d’une publication stable macOS inclut aussi les surfaces du programme de mise à jour :
|
||||
- la publication GitHub doit finalement contenir les fichiers empaquetés `.zip`, `.dmg` et `.dSYM.zip`
|
||||
- la publication npm stable peut cibler `latest` explicitement via une entrée du workflow
|
||||
- la promotion npm stable de `beta` vers `latest` reste disponible en mode manuel explicite dans le workflow de confiance `OpenClaw NPM Release`
|
||||
- les publications stables directes peuvent également exécuter un mode explicite de synchronisation des dist-tags qui fait pointer `latest` et `beta` vers la version stable déjà publiée
|
||||
- ces modes de dist-tag nécessitent toujours un `NPM_TOKEN` valide dans l’environnement `npm-release`, car la gestion des `dist-tag` npm est distincte de la publication de confiance
|
||||
- la publication publique `macOS Release` est réservée à la validation
|
||||
- la vraie publication privée mac doit réussir avec des `preflight_run_id` et `validate_run_id` privés mac réussis
|
||||
- les vrais chemins de publication promeuvent des artefacts préparés au lieu de les reconstruire une nouvelle fois
|
||||
- Pour les versions de correction stable comme `YYYY.M.D-N`, le vérificateur post-publication vérifie également le même chemin de mise à niveau en préfixe temporaire de `YYYY.M.D` vers `YYYY.M.D-N`, afin que les corrections de publication ne puissent pas laisser silencieusement les anciennes installations globales sur la charge utile stable de base
|
||||
- La pré-vérification de publication npm échoue en mode fermé sauf si le tarball inclut à la fois `dist/control-ui/index.html` et une charge utile non vide `dist/control-ui/assets/`, afin d’éviter de livrer à nouveau un tableau de bord navigateur vide
|
||||
- `pnpm test:install:smoke` applique également le budget `unpackedSize` du `npm pack` sur le tarball candidat à la mise à jour, afin que l’e2e de l’installateur détecte toute augmentation accidentelle de taille du pack avant le chemin de publication
|
||||
- Si le travail de publication a touché la planification CI, les manifestes de timing des extensions ou les matrices de test des extensions, régénérez et examinez les sorties de matrice du workflow `checks-node-extensions` gérées par le planificateur depuis `.github/workflows/ci.yml` avant l’approbation, afin que les notes de publication ne décrivent pas une disposition CI obsolète
|
||||
- La préparation d’une version macOS stable inclut également les surfaces de mise à jour :
|
||||
- la publication GitHub doit finir avec les fichiers empaquetés `.zip`, `.dmg` et `.dSYM.zip`
|
||||
- `appcast.xml` sur `main` doit pointer vers le nouveau zip stable après publication
|
||||
- l’app empaquetée doit conserver un bundle id non debug, une URL de flux Sparkle non vide, et un `CFBundleVersion` supérieur ou égal au seuil de build Sparkle canonique pour cette version de publication
|
||||
- l’app empaquetée doit conserver un identifiant de bundle non debug, une URL de flux Sparkle non vide et un `CFBundleVersion` au moins égal au plancher canonique de build Sparkle pour cette version
|
||||
|
||||
## Entrées du workflow NPM
|
||||
|
||||
`OpenClaw NPM Release` accepte ces entrées contrôlées par l’opérateur :
|
||||
|
||||
- `tag` : tag de publication requis tel que `v2026.4.2`, `v2026.4.2-1`, ou `v2026.4.2-beta.1` ; lorsque `preflight_only=true`, il peut aussi s’agir du SHA de commit `main` complet actuel sur 40 caractères pour une vérification préalable en mode validation uniquement
|
||||
- `tag` : tag de publication requis tel que `v2026.4.2`, `v2026.4.2-1` ou `v2026.4.2-beta.1` ; lorsque `preflight_only=true`, il peut aussi s’agir du SHA de commit `main` complet actuel à 40 caractères pour une pré-vérification en validation seule
|
||||
- `preflight_only` : `true` pour validation/build/package uniquement, `false` pour le vrai chemin de publication
|
||||
- `preflight_run_id` : requis sur le vrai chemin de publication afin que le workflow réutilise le tarball préparé à partir du run de vérification préalable réussi
|
||||
- `npm_dist_tag` : dist-tag npm cible pour le chemin de publication ; vaut `beta` par défaut
|
||||
- `preflight_run_id` : requis sur le vrai chemin de publication afin que le workflow réutilise le tarball préparé depuis l’exécution de pré-vérification réussie
|
||||
- `npm_dist_tag` : tag cible npm pour le chemin de publication ; vaut `beta` par défaut
|
||||
- `promote_beta_to_latest` : `true` pour ignorer la publication et déplacer une build stable `beta` déjà publiée vers `latest`
|
||||
- `sync_stable_dist_tags` : `true` pour ignorer la publication et pointer à la fois `latest` et `beta` vers une version stable déjà publiée
|
||||
- `sync_stable_dist_tags` : `true` pour ignorer la publication et faire pointer `latest` et `beta` vers une version stable déjà publiée
|
||||
|
||||
`OpenClaw Release Checks` accepte ces entrées contrôlées par l’opérateur :
|
||||
|
||||
- `ref` : tag de publication existant ou SHA de commit `main` complet actuel sur 40 caractères à valider
|
||||
- `ref` : tag de publication existant ou SHA de commit `main` complet actuel à 40 caractères à valider
|
||||
|
||||
Règles :
|
||||
|
||||
- Les tags stables et correctifs peuvent publier soit vers `beta`, soit vers `latest`
|
||||
- Les tags de prépublication beta ne peuvent publier que vers `beta`
|
||||
- Une entrée SHA de commit complet n’est autorisée que lorsque `preflight_only=true`
|
||||
- Le mode commit-SHA des vérifications de publication exige aussi le HEAD actuel de `origin/main`
|
||||
- Le vrai chemin de publication doit utiliser le même `npm_dist_tag` que celui utilisé pendant la vérification préalable ; le workflow vérifie ces métadonnées avant de poursuivre la publication
|
||||
- Le mode promotion doit utiliser un tag stable ou correctif, `preflight_only=false`, un `preflight_run_id` vide, et `npm_dist_tag=beta`
|
||||
- Le mode synchronisation des dist-tags doit utiliser un tag stable ou correctif, `preflight_only=false`, un `preflight_run_id` vide, `npm_dist_tag=latest`, et `promote_beta_to_latest=false`
|
||||
- Les modes promotion et synchronisation des dist-tags exigent aussi un `NPM_TOKEN` valide, car `npm dist-tag add` nécessite toujours une authentification npm classique ; la publication approuvée ne couvre que le chemin de publication du package
|
||||
- Les tags stables et de correction peuvent publier vers `beta` ou `latest`
|
||||
- Les tags de préversion beta ne peuvent publier que vers `beta`
|
||||
- L’entrée SHA de commit complet n’est autorisée que lorsque `preflight_only=true`
|
||||
- Le mode SHA de commit des vérifications de publication exige également le HEAD actuel de `origin/main`
|
||||
- Le vrai chemin de publication doit utiliser le même `npm_dist_tag` que celui utilisé pendant la pré-vérification ; le workflow vérifie ces métadonnées avant de poursuivre la publication
|
||||
- Le mode promotion doit utiliser un tag stable ou de correction, `preflight_only=false`, un `preflight_run_id` vide et `npm_dist_tag=beta`
|
||||
- Le mode de synchronisation des dist-tags doit utiliser un tag stable ou de correction, `preflight_only=false`, un `preflight_run_id` vide, `npm_dist_tag=latest` et `promote_beta_to_latest=false`
|
||||
- Les modes promotion et synchronisation des dist-tags exigent également un `NPM_TOKEN` valide, car `npm dist-tag add` nécessite toujours une authentification npm classique ; la publication de confiance couvre uniquement le chemin de publication du package
|
||||
|
||||
## Séquence de publication npm stable
|
||||
|
||||
Lors de la création d’une publication npm stable :
|
||||
|
||||
1. Exécutez `OpenClaw NPM Release` avec `preflight_only=true`
|
||||
- Avant qu’un tag existe, vous pouvez utiliser le SHA complet du commit `main` actuel pour un essai à blanc en mode validation uniquement du workflow de vérification préalable
|
||||
- Avant qu’un tag n’existe, vous pouvez utiliser le SHA de commit `main` complet actuel pour un essai à sec en validation seule du workflow de pré-vérification
|
||||
2. Choisissez `npm_dist_tag=beta` pour le flux normal beta-first, ou `latest` uniquement lorsque vous souhaitez intentionnellement une publication stable directe
|
||||
3. Exécutez `OpenClaw Release Checks` séparément avec le même tag ou le SHA complet actuel de `main` lorsque vous souhaitez une couverture live du cache de prompt
|
||||
- Cela est volontairement séparé pour que la couverture live reste disponible sans recoupler des vérifications longues ou instables au workflow de publication
|
||||
3. Exécutez `OpenClaw Release Checks` séparément avec le même tag ou le SHA complet actuel de `main` lorsque vous voulez une couverture live du cache de prompt
|
||||
- Cette séparation est intentionnelle afin que la couverture live reste disponible sans recoupler des vérifications longues ou instables au workflow de publication
|
||||
4. Enregistrez le `preflight_run_id` réussi
|
||||
5. Exécutez à nouveau `OpenClaw NPM Release` avec `preflight_only=false`, le même `tag`, le même `npm_dist_tag`, et le `preflight_run_id` enregistré
|
||||
6. Si la publication est arrivée sur `beta`, exécutez plus tard `OpenClaw NPM Release` avec le même `tag` stable, `promote_beta_to_latest=true`, `preflight_only=false`, `preflight_run_id` vide, et `npm_dist_tag=beta` lorsque vous souhaitez déplacer cette build publiée vers `latest`
|
||||
7. Si la publication a été intentionnellement publiée directement vers `latest` et que `beta` doit suivre la même build stable, exécutez `OpenClaw NPM Release` avec le même `tag` stable, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`, `preflight_only=false`, `preflight_run_id` vide, et `npm_dist_tag=latest`
|
||||
5. Exécutez à nouveau `OpenClaw NPM Release` avec `preflight_only=false`, le même `tag`, le même `npm_dist_tag` et le `preflight_run_id` enregistré
|
||||
6. Si la publication est arrivée sur `beta`, exécutez plus tard `OpenClaw NPM Release` avec le même `tag` stable, `promote_beta_to_latest=true`, `preflight_only=false`, un `preflight_run_id` vide et `npm_dist_tag=beta` lorsque vous souhaitez déplacer cette build publiée vers `latest`
|
||||
7. Si la publication a été intentionnellement publiée directement sur `latest` et que `beta` doit suivre la même build stable, exécutez `OpenClaw NPM Release` avec le même `tag` stable, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`, `preflight_only=false`, un `preflight_run_id` vide et `npm_dist_tag=latest`
|
||||
|
||||
Les modes promotion et synchronisation des dist-tags exigent toujours l’approbation de l’environnement `npm-release` et un `NPM_TOKEN` valide accessible à l’exécution de ce workflow.
|
||||
Les modes promotion et synchronisation des dist-tags nécessitent toujours l’approbation de l’environnement `npm-release` et un `NPM_TOKEN` valide accessible à cette exécution du workflow.
|
||||
|
||||
Cela permet de documenter et de rendre visibles pour les opérateurs à la fois le chemin de publication directe et le chemin de promotion beta-first.
|
||||
Cela permet de garder à la fois le chemin de publication directe et le chemin de promotion beta-first documentés et visibles pour l’opérateur.
|
||||
|
||||
## Références publiques
|
||||
|
||||
@ -136,4 +137,4 @@ Cela permet de documenter et de rendre visibles pour les opérateurs à la fois
|
||||
|
||||
Les mainteneurs utilisent la documentation privée de publication dans
|
||||
[`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
|
||||
pour la procédure réelle.
|
||||
comme véritable runbook.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user