Distribuzione con Zinnector®: collega, verifica, invia

Una volta che un progetto viene eseguito in locale, quattro comandi lo portano a un sito live sull'hosting di Zinn Digital®: accesso, collegamento del progetto a uno slot di hosting, lettura dei controlli preliminari e push. Questo articolo illustra ciascuno di essi, ciò che restituisce e i comandi da utilizzare successivamente: ridepoly, cronologia dei deploy e log di compilazione.

Accedi con una chiave API

Crea una chiave nella dashboard alla voce Impostazioni → Chiavi API, quindi:

zinnector login

La chiave viene digitata a prompt — non viene mai accettata dalla riga di comando, quindi non può finire nella cronologia della shell o nell'elenco dei processi. In CI, inviala tramite pipe: echo "$ZINN_API_KEY" | zinnector login --profile ci, oppure imposta ZINNECTOR_TOKEN e salta del tutto il comando login. La chiave viene verificata prima di essere memorizzata e salvata con i permessi di file 600. zinnector whoami --scopes mostra a quale organizzazione si è connessi e quali autorizzazioni possiede la chiave; una chiave sandbox viene contrassegnata come tale.

Collega il progetto a uno slot

zinnector link                                   # seleziona un sito da un elenco
zinnector link example.com --repo acme/site --branch main

Il comando link scrive l'id del sito in zinnector.json e, a meno che non si passi l'opzione --no-repo, collega il remote git del progetto al sito sulla piattaforma affinché un push ne effettui il deploy. Esegui il commit di zinnector.json: un collega che clonerà il repository eseguirà il deploy nello stesso punto senza bisogno di istruzioni. Non contiene alcun dato sensibile.

Leggi i controlli preliminari

zinnector check

Questo è il comando per cui la CLI esiste. Confronta il progetto con lo slot su cui sta per essere distribuito e mostra ogni discrepanza, oltre a ogni confronto che non è stato possibile effettuare:

Versione di PHP, con una differenza di versione major classificata come alta perché interrompe in modo affidabile un sito e una differenza minor classificata come inferiore, poiché classificare tutto come critico induce le persone a ignorare l'avviso.
Se lo slot può passare alla versione su cui si è eseguito il build, se il PHP dello slot ha superato la fine del supporto (EOL) e se la macchina ha applicato la versione o le è stato solo comunicato.
Dimensioni e numero di file del progetto rispetto allo spazio su disco e agli inode effettivamente disponibili sullo slot: un albero di WordPress può esaurire i file pur rimanendo ampiamente al di sotto del limite del disco.
Le versioni di WordPress su ciascun lato, se lo slot ha completato il provisioning e se è connesso un repository su cui effettuare il push.

Genera avvisi, non blocca mai. Ogni riserva può essere ignorata con zinnector push --force, poiché si conoscono dettagli sul proprio sito che un sistema di controllo non può conoscere. Un confronto che non è stato possibile effettuare viene segnalato come sconosciuto, mai come superato, e il riepilogo indica sempre quanti ce ne sono stati. Per impostazione predefinita, la versione locale di PHP è quella dichiarata in zinnector.json; --probe avvia il runtime locale e lo misura di conseguenza. --strict restituisce un codice di uscita diverso da zero anche in presenza di elementi sconosciuti, che è il comportamento desiderato da un controllo di CI.

Push

zinnector push

Il comando push esegue i controlli preliminari, invia i commit, attiva il deploy e ne monitora il completamento, stampando lo stato finale e il commit distribuito. L'opzione --dry-run esegue tutto tranne il deploy; --no-wait lo attiva e termina; --no-git esegue il deploy di ciò che la piattaforma possiede già senza effettuare il push. Se il commit distribuito non è quello appena inviato, viene segnalato.

Quando qualcosa va storto

zinnector deploys example.com        # cronologia dei deploy — stato, commit, trigger, messaggio
zinnector logs example.com --build   # il log di build del deploy più recente
zinnector logs example.com --error   # il log degli errori del sito
zinnector deploy example.com         # ridistribuisce ciò che la piattaforma possiede già
zinnector ai "why is my deploy failing?"

zinnector ai viene eseguito sulla piattaforma in relazione al proprio account, in modo da poter visualizzare la stessa cronologia dei deploy e gli stessi log. Dall'interno di un progetto, invia la struttura del progetto (nomi delle directory, versioni e id del sito) e mai il contenuto dei file.