chore(i18n): refresh it translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
4fa09029e1
commit
e84fa695d1
@ -1,28 +1,28 @@
|
||||
---
|
||||
read_when:
|
||||
- Vuoi servire modelli dal tuo box GPU personale
|
||||
- Stai configurando LM Studio o un proxy compatibile con OpenAI
|
||||
- Hai bisogno della guida più sicura per i modelli locali
|
||||
- Vuoi servire modelli dalla tua macchina GPU.
|
||||
- Stai configurando LM Studio o un proxy compatibile con OpenAI.
|
||||
- Ti serve la guida più sicura per i modelli locali.
|
||||
summary: Esegui OpenClaw su LLM locali (LM Studio, vLLM, LiteLLM, endpoint OpenAI personalizzati)
|
||||
title: Modelli locali
|
||||
x-i18n:
|
||||
generated_at: "2026-04-13T08:27:14Z"
|
||||
generated_at: "2026-04-14T08:16:42Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 3ecb61b3e6e34d3666f9b688cd694d92c5fb211cf8c420fa876f7ccf5789154a
|
||||
source_hash: 1544c522357ba4b18dfa6d05ea8d60c7c6262281b53863d9aee7002464703ca7
|
||||
source_path: gateway/local-models.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Modelli locali
|
||||
|
||||
Il locale è fattibile, ma OpenClaw si aspetta un contesto ampio + forti difese contro il prompt injection. Le schede piccole troncano il contesto e indeboliscono la sicurezza. Punta in alto: **≥2 Mac Studio al massimo della configurazione o una macchina GPU equivalente (~30.000$+)**. Una singola GPU da **24 GB** funziona solo per prompt più leggeri con latenza più alta. Usa la **variante di modello più grande / a dimensione piena che puoi eseguire**; checkpoint fortemente quantizzati o “small” aumentano il rischio di prompt injection (vedi [Sicurezza](/it/gateway/security)).
|
||||
Il locale è fattibile, ma OpenClaw si aspetta un contesto ampio + difese solide contro la prompt injection. Le schede piccole troncano il contesto e indeboliscono la sicurezza. Punta in alto: **≥2 Mac Studio al massimo della configurazione o una macchina GPU equivalente (~$30k+)**. Una singola GPU da **24 GB** funziona solo per prompt più leggeri con latenza più alta. Usa la **variante di modello più grande / full-size che riesci a eseguire**; checkpoint quantizzati in modo aggressivo o “small” aumentano il rischio di prompt injection (vedi [Sicurezza](/it/gateway/security)).
|
||||
|
||||
Se vuoi la configurazione locale con meno attrito, inizia con [LM Studio](/it/providers/lmstudio) o [Ollama](/it/providers/ollama) e `openclaw onboard`. Questa pagina è la guida con opinioni precise per stack locali di fascia più alta e server locali personalizzati compatibili con OpenAI.
|
||||
Se vuoi la configurazione locale con meno attrito, inizia con [LM Studio](/it/providers/lmstudio) o [Ollama](/it/providers/ollama) e `openclaw onboard`. Questa pagina è la guida con indicazioni precise per stack locali di fascia alta e server locali personalizzati compatibili con OpenAI.
|
||||
|
||||
## Consigliato: LM Studio + grande modello locale (API Responses)
|
||||
|
||||
La migliore stack locale attuale. Carica un modello grande in LM Studio (per esempio, una build completa di Qwen, DeepSeek o Llama), abilita il server locale (predefinito `http://127.0.0.1:1234`), e usa l’API Responses per mantenere il ragionamento separato dal testo finale.
|
||||
Il miglior stack locale attuale. Carica un modello grande in LM Studio (per esempio una build full-size di Qwen, DeepSeek o Llama), abilita il server locale (predefinito `http://127.0.0.1:1234`), e usa l'API Responses per mantenere il ragionamento separato dal testo finale.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -45,7 +45,7 @@ La migliore stack locale attuale. Carica un modello grande in LM Studio (per ese
|
||||
models: [
|
||||
{
|
||||
id: “my-local-model”,
|
||||
name: “Modello locale”,
|
||||
name: “Local Model”,
|
||||
reasoning: false,
|
||||
input: [“text”],
|
||||
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
|
||||
@ -62,11 +62,11 @@ La migliore stack locale attuale. Carica un modello grande in LM Studio (per ese
|
||||
**Checklist di configurazione**
|
||||
|
||||
- Installa LM Studio: [https://lmstudio.ai](https://lmstudio.ai)
|
||||
- In LM Studio, scarica la **build del modello più grande disponibile** (evita varianti “small”/fortemente quantizzate), avvia il server, conferma che `http://127.0.0.1:1234/v1/models` lo elenchi.
|
||||
- Sostituisci `my-local-model` con l’ID modello effettivo mostrato in LM Studio.
|
||||
- Mantieni il modello caricato; il caricamento a freddo aggiunge latenza di avvio.
|
||||
- In LM Studio, scarica la **build di modello più grande disponibile** (evita varianti “small”/fortemente quantizzate), avvia il server, conferma che `http://127.0.0.1:1234/v1/models` lo elenchi.
|
||||
- Sostituisci `my-local-model` con l'ID effettivo del modello mostrato in LM Studio.
|
||||
- Mantieni il modello caricato; il caricamento a freddo aggiunge latenza all'avvio.
|
||||
- Regola `contextWindow`/`maxTokens` se la tua build di LM Studio è diversa.
|
||||
- Per WhatsApp, mantieni l’API Responses così viene inviato solo il testo finale.
|
||||
- Per WhatsApp, usa l'API Responses così viene inviato solo il testo finale.
|
||||
|
||||
Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `models.mode: "merge"` così i fallback restano disponibili.
|
||||
|
||||
@ -97,7 +97,7 @@ Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `mode
|
||||
models: [
|
||||
{
|
||||
id: "my-local-model",
|
||||
name: "Modello locale",
|
||||
name: "Local Model",
|
||||
reasoning: false,
|
||||
input: ["text"],
|
||||
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
|
||||
@ -111,18 +111,18 @@ Mantieni configurati anche i modelli ospitati quando esegui in locale; usa `mode
|
||||
}
|
||||
```
|
||||
|
||||
### Locale come prima scelta con rete di sicurezza ospitata
|
||||
### Prima il locale con rete di sicurezza ospitata
|
||||
|
||||
Inverti l’ordine di primario e fallback; mantieni lo stesso blocco `providers` e `models.mode: "merge"` così puoi ripiegare su Sonnet o Opus quando la macchina locale non è disponibile.
|
||||
Inverti l'ordine di primario e fallback; mantieni lo stesso blocco providers e `models.mode: "merge"` così puoi ripiegare su Sonnet o Opus quando la macchina locale non è disponibile.
|
||||
|
||||
### Hosting regionale / instradamento dei dati
|
||||
|
||||
- Varianti MiniMax/Kimi/GLM ospitate esistono anche su OpenRouter con endpoint vincolati alla regione (ad esempio ospitati negli Stati Uniti). Scegli lì la variante regionale per mantenere il traffico nella giurisdizione desiderata continuando a usare `models.mode: "merge"` per i fallback Anthropic/OpenAI.
|
||||
- Solo locale resta il percorso più forte per la privacy; l’instradamento regionale ospitato è la via di mezzo quando ti servono funzionalità del provider ma vuoi controllare il flusso dei dati.
|
||||
- Varianti ospitate di MiniMax/Kimi/GLM esistono anche su OpenRouter con endpoint vincolati alla regione (ad esempio, ospitati negli Stati Uniti). Scegli lì la variante regionale per mantenere il traffico nella giurisdizione scelta continuando a usare `models.mode: "merge"` per i fallback Anthropic/OpenAI.
|
||||
- Solo locale resta il percorso più forte per la privacy; l'instradamento regionale ospitato è il compromesso quando ti servono funzionalità del provider ma vuoi controllare il flusso dei dati.
|
||||
|
||||
## Altri proxy locali compatibili con OpenAI
|
||||
|
||||
vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un endpoint `/v1` in stile OpenAI. Sostituisci il blocco provider sopra con il tuo endpoint e il tuo ID modello:
|
||||
vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un endpoint `/v1` in stile OpenAI. Sostituisci il blocco provider sopra con il tuo endpoint e l'ID del modello:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -136,7 +136,7 @@ vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un end
|
||||
models: [
|
||||
{
|
||||
id: "my-local-model",
|
||||
name: "Modello locale",
|
||||
name: "Local Model",
|
||||
reasoning: false,
|
||||
input: ["text"],
|
||||
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
|
||||
@ -152,23 +152,40 @@ vLLM, LiteLLM, OAI-proxy o gateway personalizzati funzionano se espongono un end
|
||||
|
||||
Mantieni `models.mode: "merge"` così i modelli ospitati restano disponibili come fallback.
|
||||
|
||||
Nota sul comportamento per backend locali/proxy `/v1`:
|
||||
Nota sul comportamento per backend locali/proxati `/v1`:
|
||||
|
||||
- OpenClaw li tratta come route proxy compatibili con OpenAI, non come endpoint OpenAI nativi
|
||||
- qui non si applica il modellamento delle richieste riservato a OpenAI nativo: niente `service_tier`, niente `store` di Responses, niente modellamento del payload di compatibilità del ragionamento OpenAI e niente suggerimenti per la cache dei prompt
|
||||
- gli header di attribuzione nascosti di OpenClaw (`originator`, `version`, `User-Agent`) non vengono iniettati su questi URL proxy personalizzati
|
||||
- OpenClaw li tratta come route proxy in stile OpenAI compatibili, non come endpoint OpenAI nativi
|
||||
- il modellamento delle richieste riservato al solo OpenAI nativo non si applica qui: niente
|
||||
`service_tier`, niente `store` di Responses, niente modellamento del payload di compatibilità del ragionamento OpenAI
|
||||
e niente suggerimenti per la cache dei prompt
|
||||
- gli header di attribuzione nascosti di OpenClaw (`originator`, `version`, `User-Agent`)
|
||||
non vengono iniettati su questi URL di proxy personalizzati
|
||||
|
||||
Note di compatibilità per backend compatibili con OpenAI più restrittivi:
|
||||
Note di compatibilità per backend compatibili con OpenAI più rigorosi:
|
||||
|
||||
- Alcuni server accettano solo `messages[].content` come stringa nelle Chat Completions, non array strutturati di content part. Imposta `models.providers.<provider>.models[].compat.requiresStringContent: true` per quegli endpoint.
|
||||
- Alcuni backend locali più piccoli o più restrittivi sono instabili con la forma completa del prompt del runtime agent di OpenClaw, soprattutto quando sono inclusi schemi di tool. Se il backend funziona per piccole chiamate dirette a `/v1/chat/completions` ma fallisce nei normali turni agente di OpenClaw, prova prima con `models.providers.<provider>.models[].compat.supportsTools: false`.
|
||||
- Se il backend continua a fallire solo su esecuzioni OpenClaw più grandi, il problema rimanente di solito è la capacità del modello/server a monte o un bug del backend, non il livello di trasporto di OpenClaw.
|
||||
- Alcuni server accettano solo `messages[].content` come stringa su Chat Completions, non
|
||||
array strutturati di parti di contenuto. Imposta
|
||||
`models.providers.<provider>.models[].compat.requiresStringContent: true` per
|
||||
quegli endpoint.
|
||||
- Alcuni backend locali più piccoli o più rigorosi sono instabili con la forma completa del prompt
|
||||
del runtime agente di OpenClaw, soprattutto quando sono inclusi gli schemi degli strumenti. Se il
|
||||
backend funziona per piccole chiamate dirette a `/v1/chat/completions` ma fallisce nei normali
|
||||
turni agente di OpenClaw, prova prima
|
||||
`models.providers.<provider>.models[].compat.supportsTools: false`.
|
||||
- Se il backend continua a fallire solo su esecuzioni OpenClaw più grandi, il problema residuo
|
||||
di solito è la capacità a monte del modello/server o un bug del backend, non il layer di
|
||||
trasporto di OpenClaw.
|
||||
|
||||
## Risoluzione dei problemi
|
||||
|
||||
- Il Gateway riesce a raggiungere il proxy? `curl http://127.0.0.1:1234/v1/models`.
|
||||
- Modello LM Studio scaricato dalla memoria? Ricaricalo; l’avvio a freddo è una causa comune di “blocco”.
|
||||
- Errori di contesto? Riduci `contextWindow` o aumenta il limite del tuo server.
|
||||
- Il server compatibile con OpenAI restituisce `messages[].content ... expected a string`? Aggiungi `compat.requiresStringContent: true` a quella voce del modello.
|
||||
- Piccole chiamate dirette a `/v1/chat/completions` funzionano, ma `openclaw infer model run` fallisce su Gemma o un altro modello locale? Disabilita prima gli schemi di tool con `compat.supportsTools: false`, poi riprova. Se il server continua a bloccarsi solo su prompt OpenClaw più grandi, trattalo come un limite del server/modello a monte.
|
||||
- Sicurezza: i modelli locali saltano i filtri lato provider; mantieni gli agenti limitati e Compaction attivo per ridurre il raggio d’impatto del prompt injection.
|
||||
- Modello LM Studio scaricato dalla memoria? Ricaricalo; l'avvio a freddo è una causa comune di “blocco”.
|
||||
- OpenClaw avvisa quando la finestra di contesto rilevata è sotto **32k** e blocca sotto **16k**. Se incontri questo controllo preliminare, aumenta il limite di contesto del server/modello o scegli un modello più grande.
|
||||
- Errori di contesto? Riduci `contextWindow` o aumenta il limite del server.
|
||||
- Il server compatibile con OpenAI restituisce `messages[].content ... expected a string`?
|
||||
Aggiungi `compat.requiresStringContent: true` a quella voce del modello.
|
||||
- Piccole chiamate dirette a `/v1/chat/completions` funzionano, ma `openclaw infer model run`
|
||||
fallisce su Gemma o un altro modello locale? Disabilita prima gli schemi degli strumenti con
|
||||
`compat.supportsTools: false`, poi riprova. Se il server continua a bloccarsi solo
|
||||
su prompt OpenClaw più grandi, trattalo come un limite a monte del server/modello.
|
||||
- Sicurezza: i modelli locali saltano i filtri lato provider; mantieni gli agenti limitati e Compaction attivo per limitare il raggio d'azione della prompt injection.
|
||||
|
||||
@ -5,10 +5,10 @@ read_when:
|
||||
summary: Canali di rilascio pubblici, denominazione delle versioni e cadenza
|
||||
title: Politica di rilascio
|
||||
x-i18n:
|
||||
generated_at: "2026-04-14T02:08:38Z"
|
||||
generated_at: "2026-04-14T08:16:37Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: fdc32839447205d74ba7a20a45fbac8e13b199174b442a1e260e3fce056c63da
|
||||
source_hash: 3eaf9f1786b8c9fd4f5a9c657b623cb69d1a485958e1a9b8f108511839b63587
|
||||
source_path: reference/RELEASING.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,114 +17,168 @@ x-i18n:
|
||||
|
||||
OpenClaw ha tre canali di rilascio pubblici:
|
||||
|
||||
- stable: release taggate che pubblicano su npm `beta` per impostazione predefinita, oppure su npm `latest` quando richiesto esplicitamente
|
||||
- stable: release con tag che pubblicano su npm `beta` per impostazione predefinita, oppure su npm `latest` quando richiesto esplicitamente
|
||||
- beta: tag di prerelease che pubblicano su npm `beta`
|
||||
- dev: la testa mobile di `main`
|
||||
- dev: la head mobile di `main`
|
||||
|
||||
## Denominazione delle versioni
|
||||
|
||||
- Versione di rilascio stable: `YYYY.M.D`
|
||||
- Versione della release stabile: `YYYY.M.D`
|
||||
- Tag Git: `vYYYY.M.D`
|
||||
- Versione di rilascio stable correttiva: `YYYY.M.D-N`
|
||||
- Versione della release di correzione stabile: `YYYY.M.D-N`
|
||||
- Tag Git: `vYYYY.M.D-N`
|
||||
- Versione di prerelease beta: `YYYY.M.D-beta.N`
|
||||
- Versione della prerelease beta: `YYYY.M.D-beta.N`
|
||||
- Tag Git: `vYYYY.M.D-beta.N`
|
||||
- Non aggiungere zeri iniziali a mese o giorno
|
||||
- `latest` indica l'attuale release npm stable promossa
|
||||
- `latest` indica l'attuale release npm stabile promossa
|
||||
- `beta` indica l'attuale destinazione di installazione beta
|
||||
- Le release stable e stable correttive pubblicano su npm `beta` per impostazione predefinita; gli operatori di rilascio possono scegliere esplicitamente `latest`, oppure promuovere in seguito una build beta verificata
|
||||
- Le release stabili e le release di correzione stabile pubblicano su npm `beta` per impostazione predefinita; gli operatori della release possono scegliere esplicitamente `latest` come destinazione, oppure promuovere in seguito una build beta verificata
|
||||
- Ogni release di OpenClaw distribuisce insieme il pacchetto npm e l'app macOS
|
||||
|
||||
## Cadenza di rilascio
|
||||
|
||||
- Le release passano prima da beta
|
||||
- Stable segue solo dopo che l'ultima beta è stata convalidata
|
||||
- La procedura di rilascio dettagliata, le approvazioni, le credenziali e le note di ripristino sono riservate ai maintainer
|
||||
- stable segue solo dopo che l'ultima beta è stata convalidata
|
||||
- La procedura dettagliata di rilascio, le approvazioni, le credenziali e le note di recupero sono
|
||||
riservate ai maintainer
|
||||
|
||||
## Controlli preliminari del rilascio
|
||||
## Controlli preliminari della release
|
||||
|
||||
- Esegui `pnpm build && pnpm ui:build` prima di `pnpm release:check` in modo che gli artifact di rilascio `dist/*` previsti e il bundle della Control UI esistano per il passaggio di convalida del pack
|
||||
- Esegui `pnpm release:check` prima di ogni release taggata
|
||||
- Esegui `pnpm build && pnpm ui:build` prima di `pnpm release:check` in modo che gli attesi
|
||||
artifact di rilascio `dist/*` e il bundle della Control UI esistano per il passaggio di
|
||||
validazione del pack
|
||||
- Esegui `pnpm release:check` prima di ogni release con tag
|
||||
- I controlli di rilascio ora vengono eseguiti in un workflow manuale separato:
|
||||
`OpenClaw Release Checks`
|
||||
- Questa separazione è intenzionale: mantiene il percorso reale di rilascio npm breve, deterministico e focalizzato sugli artifact, mentre i controlli live più lenti restano nel proprio canale così da non rallentare o bloccare la pubblicazione
|
||||
- I controlli di rilascio devono essere avviati dal workflow ref di `main` in modo che la logica del workflow e i segreti restino canonici
|
||||
- Quel workflow accetta un tag di rilascio esistente oppure l'attuale commit SHA completo di 40 caratteri di `main`
|
||||
- In modalità commit-SHA accetta solo l'attuale HEAD di `origin/main`; usa un tag di rilascio per commit di rilascio precedenti
|
||||
- Anche il controllo preliminare di sola convalida `OpenClaw NPM Release` accetta l'attuale commit SHA completo di 40 caratteri di `main` senza richiedere un tag già pubblicato
|
||||
- Quel percorso SHA è solo di convalida e non può essere promosso a una pubblicazione reale
|
||||
- In modalità SHA il workflow sintetizza `v<package.json version>` solo per il controllo dei metadati del pacchetto; la pubblicazione reale richiede comunque un vero tag di rilascio
|
||||
- Entrambi i workflow mantengono il percorso reale di pubblicazione e promozione su runner ospitati da GitHub, mentre il percorso di convalida non mutante può usare i runner Linux Blacksmith più grandi
|
||||
- Questa separazione è intenzionale: mantiene il percorso reale di release npm breve,
|
||||
deterministico e focalizzato sugli artifact, mentre i controlli live più lenti rimangono nel loro
|
||||
canale così da non rallentare o bloccare la pubblicazione
|
||||
- I controlli di rilascio devono essere avviati dal workflow ref di `main` in modo che la
|
||||
logica del workflow e i secret rimangano canonici
|
||||
- Quel workflow accetta come input un tag di release esistente oppure l'attuale commit SHA completo a 40 caratteri di `main`
|
||||
- In modalità commit-SHA accetta solo l'attuale HEAD di `origin/main`; usa un
|
||||
tag di release per commit di release precedenti
|
||||
- Anche il controllo preliminare di sola validazione `OpenClaw NPM Release` accetta l'attuale
|
||||
commit SHA completo a 40 caratteri di `main` senza richiedere un tag pubblicato
|
||||
- Il percorso basato su SHA è solo di validazione e non può essere promosso a una pubblicazione reale
|
||||
- In modalità SHA il workflow sintetizza `v<package.json version>` solo per il
|
||||
controllo dei metadati del pacchetto; la pubblicazione reale richiede comunque un vero tag di release
|
||||
- Entrambi i workflow mantengono il percorso reale di pubblicazione e promozione su runner ospitati da GitHub,
|
||||
mentre il percorso di validazione non mutante può usare i runner Linux
|
||||
Blacksmith più grandi
|
||||
- Quel workflow esegue
|
||||
`OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
|
||||
usando entrambi i secret di workflow `OPENAI_API_KEY` e `ANTHROPIC_API_KEY`
|
||||
- Il controllo preliminare della release npm non aspetta più il canale separato dei controlli di rilascio
|
||||
- Il controllo preliminare della release npm non attende più il canale separato dei controlli di rilascio
|
||||
- Esegui `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
|
||||
(o il tag beta/correttivo corrispondente) prima dell'approvazione
|
||||
(oppure il tag beta/correzione corrispondente) prima dell'approvazione
|
||||
- Dopo la pubblicazione su npm, esegui
|
||||
`node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
|
||||
(o la versione beta/correttiva corrispondente) per verificare il percorso di installazione del registro pubblicato in un prefisso temporaneo pulito
|
||||
- L'automazione di rilascio dei maintainer ora usa il modello preflight-then-promote:
|
||||
- la reale pubblicazione npm deve superare con esito positivo un `preflight_run_id` npm
|
||||
- le release npm stable usano `beta` per impostazione predefinita
|
||||
- la pubblicazione npm stable può scegliere esplicitamente `latest` tramite input del workflow
|
||||
- la promozione npm stable da `beta` a `latest` è ancora disponibile come modalità manuale esplicita nel workflow attendibile `OpenClaw NPM Release`
|
||||
- le pubblicazioni stable dirette possono anche eseguire una modalità esplicita di sincronizzazione dei dist-tag che punta sia `latest` sia `beta` alla versione stable già pubblicata
|
||||
- queste modalità dei dist-tag richiedono comunque un `NPM_TOKEN` valido nell'ambiente `npm-release` perché la gestione dei `dist-tag` di npm è separata dalla pubblicazione attendibile
|
||||
- `macOS Release` pubblico è solo di convalida
|
||||
- la vera pubblicazione privata mac deve superare con esito positivo i valori `preflight_run_id` e `validate_run_id` del preflight mac privato
|
||||
- i percorsi di pubblicazione reali promuovono artifact preparati invece di ricostruirli di nuovo
|
||||
- Per release stable correttive come `YYYY.M.D-N`, il verificatore post-pubblicazione controlla anche lo stesso percorso di aggiornamento con prefisso temporaneo da `YYYY.M.D` a `YYYY.M.D-N`, così le correzioni di rilascio non possono lasciare silenziosamente installazioni globali più vecchie sul payload stable di base
|
||||
- Il controllo preliminare della release npm fallisce in modalità closed se il tarball non include sia `dist/control-ui/index.html` sia un payload `dist/control-ui/assets/` non vuoto, così evitiamo di distribuire di nuovo una dashboard browser vuota
|
||||
- Se il lavoro di rilascio ha toccato la pianificazione CI, i manifest di temporizzazione delle estensioni o le matrici di test delle estensioni, rigenera e rivedi gli output della matrice del workflow `checks-node-extensions` gestiti dal planner da `.github/workflows/ci.yml` prima dell'approvazione, così le note di rilascio non descriveranno un layout CI obsoleto
|
||||
- La prontezza della release stable macOS include anche le superfici dell'updater:
|
||||
- la release GitHub deve finire con i file pacchettizzati `.zip`, `.dmg` e `.dSYM.zip`
|
||||
- `appcast.xml` su `main` deve puntare al nuovo zip stable dopo la pubblicazione
|
||||
- l'app pacchettizzata deve mantenere un bundle id non di debug, un URL del feed Sparkle non vuoto e un `CFBundleVersion` pari o superiore alla soglia canonica di build Sparkle per quella versione di rilascio
|
||||
(oppure la versione beta/correzione corrispondente) per verificare il percorso di
|
||||
installazione del registro pubblicato in un nuovo prefisso temporaneo
|
||||
- L'automazione di rilascio dei maintainer ora usa il modello controllo preliminare-poi-promozione:
|
||||
- la pubblicazione npm reale deve superare con successo un npm `preflight_run_id`
|
||||
- le release npm stabili usano `beta` per impostazione predefinita
|
||||
- la pubblicazione npm stabile può scegliere esplicitamente `latest` tramite input del workflow
|
||||
- la promozione npm stabile da `beta` a `latest` è ancora disponibile come modalità manuale esplicita nel workflow attendibile `OpenClaw NPM Release`
|
||||
- le pubblicazioni stabili dirette possono anche eseguire una modalità esplicita di sincronizzazione dei dist-tag che
|
||||
punta sia `latest` sia `beta` alla versione stabile già pubblicata
|
||||
- quelle modalità dist-tag richiedono comunque un `NPM_TOKEN` valido nell'ambiente `npm-release` perché la gestione dei `dist-tag` npm è separata dalla pubblicazione attendibile
|
||||
- `macOS Release` pubblico è solo di validazione
|
||||
- la pubblicazione reale privata per mac deve superare con successo i controlli preliminari privati per mac
|
||||
`preflight_run_id` e `validate_run_id`
|
||||
- i percorsi di pubblicazione reale promuovono artifact preparati invece di ricostruirli
|
||||
di nuovo
|
||||
- Per release di correzione stabile come `YYYY.M.D-N`, il verificatore post-pubblicazione
|
||||
controlla anche lo stesso percorso di aggiornamento con prefisso temporaneo da `YYYY.M.D` a `YYYY.M.D-N`
|
||||
in modo che le correzioni di rilascio non possano lasciare silenziosamente vecchie installazioni globali sul
|
||||
payload stabile di base
|
||||
- Il controllo preliminare della release npm fallisce in modo restrittivo se il tarball non include sia
|
||||
`dist/control-ui/index.html` sia un payload non vuoto `dist/control-ui/assets/`
|
||||
così da non distribuire di nuovo una dashboard browser vuota
|
||||
- `pnpm test:install:smoke` applica anche il budget `unpackedSize` del pack npm al
|
||||
tarball candidato per l'aggiornamento, così l'installer e2e intercetta l'aumento accidentale del pack
|
||||
prima del percorso di pubblicazione della release
|
||||
- Se il lavoro di release ha toccato la pianificazione CI, i manifest temporali delle estensioni o
|
||||
le matrici di test delle estensioni, rigenera e rivedi gli output della matrice del workflow
|
||||
`checks-node-extensions` posseduti dal planner da `.github/workflows/ci.yml`
|
||||
prima dell'approvazione, così le note di rilascio non descrivono un layout CI obsoleto
|
||||
- La prontezza della release stabile macOS include anche le superfici dell'updater:
|
||||
- la release GitHub deve finire con `.zip`, `.dmg` e `.dSYM.zip` pacchettizzati
|
||||
- `appcast.xml` su `main` deve puntare al nuovo zip stabile dopo la pubblicazione
|
||||
- l'app pacchettizzata deve mantenere un bundle id non di debug, un feed Sparkle URL non vuoto
|
||||
e un `CFBundleVersion` pari o superiore alla soglia canonica di build Sparkle
|
||||
per quella versione di rilascio
|
||||
|
||||
## Input del workflow NPM
|
||||
|
||||
`OpenClaw NPM Release` accetta questi input controllati dall'operatore:
|
||||
|
||||
- `tag`: tag di rilascio obbligatorio come `v2026.4.2`, `v2026.4.2-1`, oppure `v2026.4.2-beta.1`; quando `preflight_only=true`, può anche essere l'attuale commit SHA completo di 40 caratteri di `main` per un preflight solo di convalida
|
||||
- `preflight_only`: `true` per sola convalida/build/package, `false` per il percorso di pubblicazione reale
|
||||
- `preflight_run_id`: obbligatorio nel percorso di pubblicazione reale così il workflow riutilizza il tarball preparato dall'esecuzione di preflight riuscita
|
||||
- `tag`: tag di release obbligatorio come `v2026.4.2`, `v2026.4.2-1`, oppure
|
||||
`v2026.4.2-beta.1`; quando `preflight_only=true`, può anche essere l'attuale
|
||||
commit SHA completo a 40 caratteri di `main` per un controllo preliminare di sola validazione
|
||||
- `preflight_only`: `true` per sola validazione/build/package, `false` per il
|
||||
percorso di pubblicazione reale
|
||||
- `preflight_run_id`: obbligatorio nel percorso di pubblicazione reale in modo che il workflow riutilizzi
|
||||
il tarball preparato dal controllo preliminare riuscito
|
||||
- `npm_dist_tag`: tag npm di destinazione per il percorso di pubblicazione; il valore predefinito è `beta`
|
||||
- `promote_beta_to_latest`: `true` per saltare la pubblicazione e spostare su `latest` una build stable `beta` già pubblicata
|
||||
- `sync_stable_dist_tags`: `true` per saltare la pubblicazione e far puntare sia `latest` sia `beta` a una versione stable già pubblicata
|
||||
- `promote_beta_to_latest`: `true` per saltare la pubblicazione e spostare una build stabile `beta`
|
||||
già pubblicata su `latest`
|
||||
- `sync_stable_dist_tags`: `true` per saltare la pubblicazione e far puntare sia `latest` sia
|
||||
`beta` a una versione stabile già pubblicata
|
||||
|
||||
`OpenClaw Release Checks` accetta questi input controllati dall'operatore:
|
||||
|
||||
- `ref`: tag di rilascio esistente oppure l'attuale commit SHA completo di 40 caratteri di `main` da convalidare
|
||||
- `ref`: tag di release esistente oppure l'attuale commit
|
||||
SHA completo a 40 caratteri di `main` da convalidare
|
||||
|
||||
Regole:
|
||||
|
||||
- I tag stable e correttivi possono pubblicare su `beta` o `latest`
|
||||
- I tag stabili e di correzione possono pubblicare sia su `beta` sia su `latest`
|
||||
- I tag di prerelease beta possono pubblicare solo su `beta`
|
||||
- L'input SHA del commit completo è consentito solo quando `preflight_only=true`
|
||||
- L'input con commit SHA completo è consentito solo quando `preflight_only=true`
|
||||
- La modalità commit-SHA dei controlli di rilascio richiede anche l'attuale HEAD di `origin/main`
|
||||
- Il percorso di pubblicazione reale deve usare lo stesso `npm_dist_tag` usato durante il preflight; il workflow verifica quei metadati prima di continuare la pubblicazione
|
||||
- La modalità promozione deve usare un tag stable o correttivo, `preflight_only=false`, un `preflight_run_id` vuoto e `npm_dist_tag=beta`
|
||||
- La modalità di sincronizzazione dei dist-tag deve usare un tag stable o correttivo, `preflight_only=false`, un `preflight_run_id` vuoto, `npm_dist_tag=latest` e `promote_beta_to_latest=false`
|
||||
- Le modalità promozione e sincronizzazione dei dist-tag richiedono anche un `NPM_TOKEN` valido perché `npm dist-tag add` richiede ancora l'autenticazione npm normale; la pubblicazione attendibile copre solo il percorso di pubblicazione del pacchetto
|
||||
- Il percorso di pubblicazione reale deve usare lo stesso `npm_dist_tag` usato durante il controllo preliminare;
|
||||
il workflow verifica quei metadati prima che la pubblicazione prosegua
|
||||
- La modalità di promozione deve usare un tag stabile o di correzione, `preflight_only=false`,
|
||||
un `preflight_run_id` vuoto e `npm_dist_tag=beta`
|
||||
- La modalità di sincronizzazione dist-tag deve usare un tag stabile o di correzione,
|
||||
`preflight_only=false`, un `preflight_run_id` vuoto, `npm_dist_tag=latest`,
|
||||
e `promote_beta_to_latest=false`
|
||||
- Le modalità di promozione e sincronizzazione dist-tag richiedono anche un `NPM_TOKEN` valido perché
|
||||
`npm dist-tag add` richiede ancora la normale autenticazione npm; la pubblicazione attendibile copre
|
||||
solo il percorso di pubblicazione del pacchetto
|
||||
|
||||
## Sequenza di rilascio npm stable
|
||||
## Sequenza della release npm stabile
|
||||
|
||||
Quando prepari una release npm stable:
|
||||
Quando si prepara una release npm stabile:
|
||||
|
||||
1. Esegui `OpenClaw NPM Release` con `preflight_only=true`
|
||||
- Prima che esista un tag, puoi usare l'attuale commit SHA completo di `main` per una prova a secco solo di convalida del workflow di preflight
|
||||
2. Scegli `npm_dist_tag=beta` per il normale flusso beta-first, oppure `latest` solo quando vuoi intenzionalmente una pubblicazione stable diretta
|
||||
3. Esegui separatamente `OpenClaw Release Checks` con lo stesso tag o con l'attuale commit SHA completo di `main` quando vuoi una copertura live della cache dei prompt
|
||||
- Questo è separato di proposito così la copertura live resta disponibile senza riaccoppiare controlli lunghi o instabili al workflow di pubblicazione
|
||||
- Prima che esista un tag, puoi usare l'attuale commit SHA completo di `main` per un
|
||||
dry run di sola validazione del workflow di controllo preliminare
|
||||
2. Scegli `npm_dist_tag=beta` per il normale flusso beta-first, oppure `latest` solo
|
||||
quando vuoi intenzionalmente una pubblicazione stabile diretta
|
||||
3. Esegui `OpenClaw Release Checks` separatamente con lo stesso tag oppure con il
|
||||
commit SHA completo attuale di `main` quando vuoi la copertura live della prompt cache
|
||||
- Questo è separato apposta così la copertura live resta disponibile senza
|
||||
riaccoppiare controlli lunghi o instabili al workflow di pubblicazione
|
||||
4. Salva il `preflight_run_id` riuscito
|
||||
5. Esegui di nuovo `OpenClaw NPM Release` con `preflight_only=false`, lo stesso `tag`, lo stesso `npm_dist_tag` e il `preflight_run_id` salvato
|
||||
6. Se la release è arrivata su `beta`, esegui successivamente `OpenClaw NPM Release` con lo stesso `tag` stable, `promote_beta_to_latest=true`, `preflight_only=false`, `preflight_run_id` vuoto e `npm_dist_tag=beta` quando vuoi spostare quella build pubblicata su `latest`
|
||||
7. Se la release è stata intenzionalmente pubblicata direttamente su `latest` e `beta` deve seguire la stessa build stable, esegui `OpenClaw NPM Release` con lo stesso `tag` stable, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`, `preflight_only=false`, `preflight_run_id` vuoto e `npm_dist_tag=latest`
|
||||
5. Esegui di nuovo `OpenClaw NPM Release` con `preflight_only=false`, lo stesso
|
||||
`tag`, lo stesso `npm_dist_tag` e il `preflight_run_id` salvato
|
||||
6. Se la release è arrivata su `beta`, esegui `OpenClaw NPM Release` più tardi con lo
|
||||
stesso `tag` stabile, `promote_beta_to_latest=true`, `preflight_only=false`,
|
||||
`preflight_run_id` vuoto e `npm_dist_tag=beta` quando vuoi spostare quella
|
||||
build pubblicata su `latest`
|
||||
7. Se la release è stata intenzionalmente pubblicata direttamente su `latest` e `beta`
|
||||
deve seguire la stessa build stabile, esegui `OpenClaw NPM Release` con lo stesso
|
||||
`tag` stabile, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`,
|
||||
`preflight_only=false`, `preflight_run_id` vuoto e `npm_dist_tag=latest`
|
||||
|
||||
Le modalità promozione e sincronizzazione dei dist-tag richiedono comunque l'approvazione dell'ambiente `npm-release` e un `NPM_TOKEN` valido accessibile a quell'esecuzione del workflow.
|
||||
Le modalità di promozione e sincronizzazione dist-tag richiedono comunque l'approvazione dell'ambiente `npm-release`
|
||||
e un `NPM_TOKEN` valido accessibile a quell'esecuzione del workflow.
|
||||
|
||||
Questo mantiene sia il percorso di pubblicazione diretta sia il percorso di promozione beta-first documentati e visibili agli operatori.
|
||||
Questo mantiene sia il percorso di pubblicazione diretta sia il percorso di promozione beta-first
|
||||
documentati e visibili agli operatori.
|
||||
|
||||
## Riferimenti pubblici
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user