Come eseguire il deploy di un monorepo sulla piattaforma cloud Cloud Noce?

Un repository può contenere più servizi Cloud Noce. Ogni servizio ha comandi di build e avvio, variabili, domini, numero di istanze e versioni di release indipendenti; puoi gestirli tutti nello stesso progetto e ambiente.

repo/
├── apps/
│   ├── web/       # servizio web
│   └── api/       # servizio API
├── packages/
│   └── shared/    # pacchetto condiviso
├── package.json
└── pnpm-lock.yaml

• Cartella root: Percorso della cartella del servizio rispetto alla root del repository; per l'API usa apps/api. Il rilevamento dello stack e l'esecuzione dei comandi di build e avvio partono da questa cartella.
• Percorso del Dockerfile: Percorso del file relativo alla root del repository, per esempio apps/api/Dockerfile. Un Dockerfile specificato esplicitamente ha sempre la precedenza sul rilevamento automatico.
• Contesto di build: Solo per l'uso con un Dockerfile; il valore . rende accessibili i lockfile e i pacchetti condivisi nella root tramite COPY . Se il campo è vuoto, il contesto coincide con la «cartella root».

Se per la build l'applicazione ha bisogno di un lockfile o di pacchetti esterni alla propria cartella, tieni il Dockerfile nella cartella dell'app e imposta il «contesto di build» sulla root del repository.

# Campi di configurazione della build nel pannello Cloud Noce
Cartella root:    apps/api
Percorso Dockerfile: apps/api/Dockerfile
Contesto di build: .
Percorsi monitorati:
  apps/api/**
  packages/shared/**
  pnpm-lock.yaml

Nel Dockerfile, i percorsi COPY sono relativi al «contesto di build». Se non hai un Dockerfile, Cloud Noce esegue Nixpacks o il builder dello stack integrato dalla «cartella root» e ignora il contesto di build personalizzato. Un progetto che dipende da file nella root richiede quindi in genere un Dockerfile con il contesto impostato sulla root del repository.

Per un servizio collegato a Git, un push sul branch collegato avvia una nuova build solo se almeno un file modificato corrisponde ai «percorsi monitorati». Se l'elenco è vuoto, ogni push genera un deploy.

• apps/api Include tutti i file in questo percorso.
• apps/api/** Corrisponde a qualsiasi profondità sotto questo percorso.
• apps/* Accetta solo una parte del percorso e non copre i file profondi.
• Aggiungi pattern separati per lockfile, configurazione nella root e pacchetti condivisi.
• Se GitHub non fornisce un elenco affidabile dei file modificati in un push molto grande, Cloud Noce ricostruisce il servizio per evitare di saltare una release.

Per un'origine locale, la CLI comprime l'intero repository specificato e imposta la directory root su--root-dir .

cd repo
gerdoo deploy . \
  --name api \
  --root-dir apps/api \
  --dockerfile apps/api/Dockerfile \
  --build-context . \
  --port 8080

Per un servizio Git esistente, puoi aggiornare le impostazioni del monorepo e i percorsi monitorati:

gerdoo service update api \
  --root-dir apps/api \
  --dockerfile apps/api/Dockerfile \
  --build-context . \
  --watch-path 'apps/api/**' \
  --watch-path 'packages/shared/**' \
  --watch-path pnpm-lock.yaml

1. Imposta una cartella root e un percorso di health check distinti per ogni servizio.
2. Aggiungi i pacchetti condivisi e i lockfile ai percorsi monitorati di tutti i servizi che li usano.
3. Imposta le variabili condivise a livello di progetto o ambiente e i valori segreti specifici a livello di servizio.
4. Modifica solo il servizio web e verifica che l'API non venga ricompilata senza motivo.
5. Modifica il pacchetto condiviso e verifica che tutti i servizi che lo usano vengano pubblicati.
6. Controlla i log di build per verificare che siano stati selezionati il builder, il Dockerfile e il contesto previsti.
7. Esegui il rollback di ogni servizio separatamente e verifica la comunicazione tra i servizi.