Come aggiungere Lighthouse a un sistema di integrazione continua, ad esempio Azioni GitHub.
Lighthouse CI è una suite per usare Lighthouse durante l'integrazione continua. L'CI di Lighthouse può essere integrati nei flussi di lavoro degli sviluppatori in molti modi diversi. Questa guida tratta i seguenti argomenti:
- Utilizzo dell'interfaccia a riga di comando CI di Lighthouse.
- Configurazione del provider CI per l'esecuzione di Lighthouse CI.
- Configurare un'azione GitHub e stato controlla per Lighthouse CI. I risultati di Lighthouse verranno visualizzati automaticamente su Richieste di pull GitHub.
- Creazione di una dashboard sul rendimento e di un datastore per i report Lighthouse.
Panoramica
Lighthouse CI è una suite di strumenti senza costi che facilitano l'utilizzo di Lighthouse per il monitoraggio delle prestazioni. Un singolo report Lighthouse fornisce un'istantanea di un sito web le prestazioni della pagina al momento in cui viene eseguita; L'CI di Lighthouse mostra come questi i risultati sono cambiati nel tempo. Questo può essere utilizzato per identificare l'impatto particolari modifiche al codice o garantire che vengano raggiunte le soglie di prestazioni durante processi di integrazione continua. Sebbene il monitoraggio delle prestazioni sia la caso d'uso comune di Lighthouse CI, può essere usato per monitorare altri aspetti il report Lighthouse, ad esempio SEO o accessibilità.
La funzionalità di base di CI di Lighthouse è fornita dal comando CI di Lighthouse
a riga di comando. (Nota: si tratta di uno strumento separato rispetto a Lighthouse
interfaccia a riga di comando. La
L'interfaccia a riga di comando CI di Lighthouse fornisce un insieme
comandi
per l'utilizzo di Lighthouse CI. Ad esempio, il comando autorun esegue più volte
Lighthouse viene eseguito, identifica il report Lighthouse medio e carica il report
per l'archiviazione. Questo comportamento può essere fortemente personalizzato
attraverso l'invio di flag
o personalizzando il file di configurazione della CI di Lighthouse, lighthouserc.js.
Sebbene la funzionalità di base di Lighthouse CI sia principalmente l'interfaccia a riga di comando CI di Lighthouse, questa CI viene in genere utilizzata tramite uno dei i seguenti approcci:
- Esecuzione di CI di Lighthouse nell'ambito dell'integrazione continua
- Utilizzo di un'azione GitHub CI Lighthouse che viene eseguita e commenta ogni pull richiesta
- Monitoraggio del rendimento nel tempo tramite la dashboard fornita da Lighthouse Server.
Tutti questi approcci si basano sull'interfaccia a riga di comando CI di Lighthouse.
Le alternative a CI Lighthouse includono il monitoraggio delle prestazioni di terze parti o scrivendo uno script per raccogliere i dati sulle prestazioni durante la CI e il processo di sviluppo. Ti consigliamo di utilizzare un servizio di terze parti se preferisci qualcun altro gestisce la gestione del tuo server di monitoraggio delle prestazioni. test dei dispositivi o, se vuoi funzionalità di notifica (come email o Slack integrazione) senza dover creare personalmente queste funzionalità.
Usa Lighthouse CI in locale
Questa sezione spiega come eseguire e installare l'interfaccia a riga di comando CI di Lighthouse in locale e
come configurare lighthouserc.js. L'esecuzione in locale dell'interfaccia a riga di comando CI di Lighthouse è
per assicurarti che lighthouserc.js sia configurato correttamente.
Installa l'interfaccia a riga di comando CI di Lighthouse.
npm install -g @lhci/cliLa CI di Lighthouse viene configurata inserendo un file
lighthouserc.jsnella radice di del repository del progetto. Questo file è obbligatorio e conterrà CI Lighthouse e le relative informazioni di configurazione. Sebbene la CI di Lighthouse possa essere configurata da utilizzare senza un file Git repository, le istruzioni in questo articolo presuppongono che il repository del progetto sia configurato utilizza git.Nella radice del repository, crea una configurazione
lighthouserc.jsun file YAML.touch lighthouserc.jsAggiungi il seguente codice a
lighthouserc.js. Il codice è vuoto Configurazione CI Lighthouse. Aggiungerai a questa configurazione passaggi successivi.module.exports = { ci: { collect: { /* Add configuration here */ }, upload: { /* Add configuration here */ }, }, };Ogni volta che viene eseguita la CI di Lighthouse, avvia un server per pubblicare il tuo sito. È questo server che consente a Lighthouse di caricare il tuo sito anche quando non ci sono altri sono in esecuzione i server. Al termine dell'esecuzione, la CI di Lighthouse arresta automaticamente il server. Per assicurarti che la pubblicazione funzioni correttamente, devi configurare
staticDistDirostartServerCommandproprietà.Se il tuo sito è statico, aggiungi la proprietà
staticDistDiraci.collectper indicare la posizione dei file statici. CI di Lighthouse utilizzerà il proprio server per pubblicare questi file durante il test del tuo sito. Se le tue il sito non è statico, aggiungi la proprietàstartServerCommandallaci.collectper indicare il comando che avvia il server. CI Lighthouse avvia un nuovo processo del server durante il test e lo arresta in seguito.// Static site example collect: { staticDistDir: './public', }// Dynamic site example collect: { startServerCommand: 'npm run start', }Aggiungi il parametro
urlall'oggettoci.collectper indicare gli URL di CI di Lighthouse su cui eseguire Lighthouse. Il valore della proprietàurldeve essere forniti sotto forma di array di URL; questo array può contenere uno o più URL. Di per impostazione predefinita, Lighthouse CI eseguirà Lighthouse tre volte su ciascun URL.collect: { // ... url: ['http://localhost:8080'] }Aggiungi il parametro
targetsull'oggettoci.uploade imposta il valore su'temporary-public-storage'. Report Lighthouse raccolti da La CI di Lighthouse verrà caricata nello spazio di archiviazione pubblico temporaneo. Il report vi rimarranno per sette giorni prima di essere eliminati automaticamente. Questa configurazione utilizza l'opzione "Spazio di archiviazione pubblico temporaneo" di caricamento perché è veloce per la configurazione. Per informazioni su altri modi per archiviare i report di Lighthouse, consulta alla documentazione.upload: { target: 'temporary-public-storage', }La posizione di archiviazione del report sarà simile a questa:
https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.htmlQuesto URL non funzionerà perché il report è già stato eliminato.
Esegui l'interfaccia a riga di comando CI di Lighthouse dal terminale utilizzando il comando
autorun. Lighthouse verrà eseguito tre volte e verrà caricato il Lighthouse mediano report.lhci autorunSe hai configurato correttamente CI Lighthouse, l'esecuzione di questo comando dovrebbe produrrà un output simile a questo:
✅ .lighthouseci/ directory writable ✅ Configuration file found ✅ Chrome installation found ⚠️ GitHub token not set Healthcheck passed! Started a web server on port 65324... Running Lighthouse 3 time(s) on http://localhost:65324/index.html Run #1...done. Run #2...done. Run #3...done. Done running Lighthouse! Uploading median LHR of http://localhost:65324/index.html...success! Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591720514021-82403.report.html No GitHub token set, skipping GitHub status check. Done running autorun.Puoi ignorare il messaggio
GitHub token not setnell'output della console. R Il token GitHub è necessario solo se vuoi utilizzare CI Lighthouse con un GitHub Azione. La configurazione di un'azione GitHub è spiegata più avanti in questo articolo.Facendo clic sul link nell'output che inizia con
https://storage.googleapis.com...ti reindirizzerà al report Lighthouse corrispondente all'esecuzione mediana di Lighthouse.I valori predefiniti utilizzati da
autorunpossono essere sostituiti tramite la riga di comando oppurelighthouserc.js. Ad esempio, la configurazionelighthouserc.jsriportata di seguito indica che è necessario raccogliere cinque esecuzioni di Lighthouse ogni volta cheautorun.Aggiorna
lighthouserc.jsper utilizzare la proprietànumberOfRuns:module.exports = { // ... collect: { numberOfRuns: 5 }, // ... }, };Esegui di nuovo il comando
autorun:lhci autorunL'output del terminale dovrebbe mostrare che Lighthouse è stato eseguito cinque volte rispetto ai tre predefiniti:
✅ .lighthouseci/ directory writable ✅ Configuration file found ✅ Chrome installation found ⚠️ GitHub token not set Healthcheck passed! Automatically determined ./dist as `staticDistDir`. Set it explicitly in lighthouserc.json if incorrect. Started a web server on port 64444... Running Lighthouse 5 time(s) on http://localhost:64444/index.html Run #1...done. Run #2...done. Run #3...done. Run #4...done. Run #5...done. Done running Lighthouse! Uploading median LHR of http://localhost:64444/index.html...success! Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591716944028-6048.report.html No GitHub token set, skipping GitHub status check. Done running autorun.Per scoprire di più sulle altre opzioni di configurazione, consulta CI di Lighthouse di configurazione documentazione.
Configura il tuo processo CI per eseguire Lighthouse CI
Lighthouse CI può essere utilizzato con il tuo strumento CI preferito. Il riquadro Configura CI Fornitore della documentazione CI di Lighthouse contiene esempi di codice che mostrano come Integrare la CI di Lighthouse nei file di configurazione degli strumenti di CI più comuni. Nello specifico, questi esempi di codice mostrano come eseguire CI di Lighthouse per raccogliere le misurazioni delle prestazioni durante il processo di CI.
L'utilizzo di Lighthouse CI per raccogliere le misurazioni delle prestazioni è un buon punto di partenza
con il monitoraggio delle prestazioni. Tuttavia, gli utenti avanzati potrebbero voler fare un passo avanti
e utilizzare la CI di Lighthouse per fare in modo che le build non vadano a buon fine se non soddisfano le
come il superamento di determinati controlli Lighthouse o che soddisfano tutte le prestazioni
budget. Questo comportamento viene configurato tramite
assert
del file lighthouserc.js.
Lighthouse CI supporta tre livelli di asserzioni:
off: ignora asserzioniwarn: errori di stampa su Stderrerror: errori di stampa per stderr e uscire da CI Lighthouse con un valore diverso da zero uscita codice
Di seguito è riportato un esempio di configurazione di lighthouserc.js che include
le asserzioni. Imposta le asserzioni relative ai punteggi delle prestazioni di Lighthouse e
categorie di accessibilità. Per fare una prova, aggiungi le asserzioni mostrate di seguito a
il file lighthouserc.js, quindi esegui nuovamente CI di Lighthouse.
module.exports = {
ci: {
collect: {
// ...
},
assert: {
assertions: {
'categories:performance': ['warn', {minScore: 1}],
'categories:accessibility': ['error', {minScore: 1}]
}
},
upload: {
// ...
},
},
};
L'output della console che genera è simile al seguente:
Per saperne di più sulle asserzioni CI di Lighthouse, consulta documentazione.
Configura un'azione GitHub per eseguire CI di Lighthouse
È possibile usare un'azione GitHub per eseguire CI Lighthouse. Verrà generato un nuovo report Lighthouse ogni volta che un codice della modifica viene eseguito il push a qualsiasi ramo di un repository GitHub. Da utilizzare insieme con uno stato verifica per visualizzare questi risultati su ogni richiesta di pull.
Nella radice del repository, crea una directory denominata
.github/workflows. La flussi di lavoro per il tuo progetto andranno in questa directory. Un flusso di lavoro è un processo che viene eseguito in un momento prestabilito (ad esempio, quando viene eseguito il push del codice) e viene composto da una o più azioni.mkdir .github mkdir .github/workflowsIn
.github/workflowscrea un file denominatolighthouse-ci.yaml. Questo file conserverà la configurazione per un nuovo flusso di lavoro.touch lighthouse-ci.yamlAggiungi il seguente testo a
lighthouse-ci.yaml.name: Build project and run Lighthouse CI on: [push] jobs: lhci: name: Lighthouse CI runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Use Node.js 10.x uses: actions/setup-node@v1 with: node-version: 10.x - name: npm install run: | npm install - name: run Lighthouse CI run: | npm install -g @lhci/cli@0.3.x lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"Questa configurazione imposta un flusso di lavoro costituito da un singolo job che verrà eseguito ogni volta che viene eseguito il push di nuovo codice nel repository. Questo job prevede quattro passaggi:
- Controlla il repository su cui verrà eseguita la CI di Lighthouse
- Installa e configura nodo
- Installa i pacchetti npm richiesti
- Esegui Lighthouse CI e carica i risultati nello spazio di archiviazione pubblico temporaneo.
Esegui il commit delle modifiche ed eseguine il push su GitHub. Se hai seguito correttamente i passaggi precedenti, il push del codice a GitHub attiverà l'esecuzione del flusso di lavoro che hai appena aggiunto.
Per verificare che la CI di Lighthouse sia stata attivata e visualizzare il report generate, vai alla scheda Azioni del progetto. Dovresti vedere l'etichetta Crea progetto ed esegui il flusso di lavoro CI di Lighthouse elencati sotto commit recente.
Puoi accedere al report Lighthouse corrispondente a un determinato commit dalla scheda Azioni. Fai clic sul commit, quindi sull'CI Lighthouse passaggio del flusso di lavoro, quindi espandi i risultati del passaggio Esegui CI di Lighthouse.
Hai appena configurato un'azione GitHub per eseguire CI di Lighthouse. Questa sarà la utile quando utilizzato insieme a uno stato GitHub controllo.
Configura un controllo dello stato su GitHub
Per controllo dello stato, se configurato, è un messaggio che viene visualizzato su ogni PR e in genere include informazioni quali i risultati di un test o l'esito positivo di creare.
I passaggi riportati di seguito spiegano come configurare un controllo dello stato per Lighthouse CI.
Vai all'app GitHub di Lighthouse CI pagina e fai clic su Configura.
(Facoltativo) Se fai parte di più organizzazioni su GitHub, scegli il organizzazione proprietaria del repository per cui vuoi utilizzare Lighthouse CI.
Seleziona Tutti i repository se vuoi abilitare Lighthouse CI in tutti o seleziona Seleziona solo i repository se vuoi utilizzare solo in repository specifici e quindi selezionare i repository. Quindi fai clic su Installa e Autorizza.
Copia il token visualizzato. Lo utilizzerai nel passaggio successivo.
Per aggiungere il token, vai alla pagina Settings (Impostazioni) del tuo GitHub repository, fai clic su Secret e poi su Aggiungi un nuovo secret.
Imposta il campo Nome su
LHCI_GITHUB_APP_TOKENe imposta il Valore al token copiato nell'ultimo passaggio, quindi fai clic sul pulsante Aggiungi di Google.Vai al file
lighthouse-ci.yamle aggiungi il nuovo secret di ambiente a "Esegui CI di Lighthouse" .
- name: run Lighthouse CI
run: |
npm install -g @lhci/cli@0.3.x
lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
+ env:
+ LHCI_GITHUB_APP_TOKEN: $
- Il controllo dello stato è pronto per l'uso. Per testarlo, crea un nuovo pull richiesta o eseguire il push di un commit a una richiesta di pull esistente.
Configura il server CI di Lighthouse
Il server CI di Lighthouse fornisce una dashboard per l'esplorazione della cronologia Segnalazioni Lighthouse. Può anche fungere da datastore privato a lungo termine Report Lighthouse.
- Scegli i commit da confrontare.
- L'importo del punteggio di Lighthouse è cambiato tra i due commit.
- Questa sezione mostra solo le metriche che sono cambiate tra i due commit.
- Le regressioni sono evidenziate in rosa.
- I miglioramenti sono evidenziati in blu.
Lighthouse CI Server è più adatto agli utenti che preferiscono eseguire il deployment per gestire la propria infrastruttura.
Per informazioni sulla configurazione del server CI di Lighthouse, incluse ricette per usando Heroku e Docker per il deployment, consulta questi istruzioni.