Rimuovere elementi, creare notifiche di stato e configurare le protezioni dell'ambiente
Questa unità illustra come rimuovere gli artefatti del flusso di lavoro da GitHub e modificare il periodo di conservazione predefinito. Verranno quindi riportate informazioni su come creare una notifica sullo stato del flusso di lavoro e come aggiungerla al file README.md. Infine, sono disponibili informazioni su come indentificare importanti protezioni dell'ambiente del flusso di lavoro e come abilitarle.
Rimuovere gli artefatti del flusso di lavoro da GitHub
Per impostazione predefinita, GitHub archivia tutti i log di compilazione e gli artefatti caricati per 90 giorni prima di eliminarli. È possibile personalizzare il periodo di conservazione in base al tipo di repository e ai limiti di utilizzo impostati per il prodotto GitHub specifico. Sono disponibili molte altre informazioni sui limiti di utilizzo e sulla conservazione degli artefatti. Per altre informazioni, vedere Limiti di utilizzo, fatturazione e amministrazione.
Si supponga tuttavia di raggiungere il limite di archiviazione dell'organizzazione per gli artefatti e i pacchetti GitHub. Si vogliono rimuovere elementi obsoleti senza aumentare i limiti di utilizzo e bloccare i flussi di lavoro. È possibile recuperare le risorse di archiviazione usate di GitHub Actions eliminando gli artefatti prima che scadano in GitHub. È possibile eseguire questa operazione in due modi, come descritto nelle sezioni seguenti. Entrambi i metodi richiedono l'accesso in scrittura al repository.
Avviso
Tenere presente che un artefatto, una volta eliminato, non può essere ripristinato.
Eliminare manualmente gli artefatti dal repository
Per eliminare manualmente un artefatto in GitHub, è necessario passare alla scheda Azioni, selezionare il flusso di lavoro dalla barra laterale sinistra e quindi scegliere l'esecuzione da visualizzare.
In Artefatti eliminare l'artefatto da rimuovere.
Per eliminare gli artefatti è anche possibile usare l'API REST Artifacts, Questa API consente anche di scaricare e recuperare informazioni sugli artefatti di lavoro.
Modificare il periodo di conservazione predefinito
È possibile modificare il periodo di conservazione predefinito degli artefatti e dei log per il repository, l'organizzazione o l'account aziendale. Tenere presente che la modifica del periodo di conservazione si applica solo ai nuovi artefatti e ai file di log. Non si applica agli oggetti esistenti. Il processo per configurare queste impostazioni è leggermente diverso per un repository, un'organizzazione o un'azienda. Per altre informazioni sulla configurazione delle conservazioni degli artefatti e dei log, vedere il riepilogo alla fine di questo modulo.
Oltre alle impostazioni configurate in un repository, un'organizzazione o un'azienda, è possibile definire un periodo di conservazione personalizzato per singoli artefatti direttamente all'interno del file del flusso di lavoro. Questa opzione è ideale per i casi d'uso singoli in cui si desidera che la conservazione di un artefatto specifico sia diversa dall'impostazione predefinita o configurata. Questa operazione può essere eseguita usando un valore retention-days all'interno del passaggio con l'azione upload-artifact.
Nell'esempio seguente viene caricato un artefatto che viene conservato per 10 giorni anziché per i 90 giorni predefiniti:
- name: 'Upload Artifact'
uses: actions/upload-artifact@v2
with:
name: my-artifact
path: my_file.txt
retention-days: 10
Aggiungere una notifica di stato del flusso di lavoro al repository
È utile conoscere lo stato di un flusso di lavoro senza dover visitare la scheda Azioni per verificare se è stato completato correttamente. L'aggiunta di notifiche di stato del flusso di lavoro al file README.md del repository consente di verificare rapidamente se i flussi di lavoro vengono eseguiti correttamente o hanno esito negativo. Sebbene sia comune aggiungere una notifica di stato a un file README.md del repository, è possibile anche aggiungerla a qualsiasi pagina Web. Per impostazione predefinita, le notifiche di stato visualizzano gli stati del flusso di lavoro nel ramo predefinito, ma è anche possibile visualizzare notifiche di stato del flusso di lavoro in altri rami usando i parametri branch e event.
Ecco un esempio degli elementi da aggiungere a un file per visualizzare una notifica di stato del flusso di lavoro:
Ad esempio, se alla nella parte finale dell'URL si aggiunge il parametro branch, oltre che al nome del ramo desiderato, viene visualizzata la notifica di stato del flusso di lavoro per tale ramo anziché per il ramo predefinito. In questo modo è facile creare una visualizzazione simile a una tabella all'interno del file README.md per visualizzare gli stati del flusso di lavoro in base, ad esempio, a rami, eventi, servizi o ambienti.
È anche possibile creare una notifica di stato usando GitHub. Passare alla sezione sui flussi di lavoro all'interno della scheda Azioni e selezionare un flusso di lavoro specifico. L'opzione Crea notifica di stato consente di generare il markdown per tale flusso di lavoro e di impostare i parametri branch e event.
Aggiungere protezioni dell'ambiente del flusso di lavoro
La sicurezza è molto importante, quindi è opportuno configurare l'ambiente del flusso di lavoro con segreti e regole di protezione. Avendo definito questi elementi, un processo non viene avviato e non accede ad alcun segreto definito nell'ambiente fino a quando non vengono superate tutte le regole di protezione dell'ambiente. Al momento, le regole di protezione e i segreti dell'ambiente si applicano solo ai repository pubblici.
Esistono due regole di protezione dell'ambiente che possono essere applicate ai flussi di lavoro all'interno di repository pubblici, i revisori obbligatori e il timer di attesa.
- I revisori obbligatori consentono di impostare una persona o un team specifico per approvare i processi del flusso di lavoro che fanno riferimento all'ambiente del processo.
- Il timer di attesa può essere usato per ritardare un processo per un periodo di tempo specifico dopo che è stato attivato.
Si supponga di dover creare un flusso di lavoro in un ambiente di produzione che, prima di essere distribuito, deve essere approvato da un team di sviluppo. Eseguire la procedura descritta di seguito:
- Creare un ambiente di produzione all'interno del repository.
- Configurare la protezione dell'ambiente dei revisori obbligatori perché richieda un'approvazione da parte del team di sviluppo specifico.
- Configurare il processo specifico all'interno del flusso di lavoro perché cerchi l'ambiente di produzione.
È possibile creare e configurare nuovi ambienti del repository dalla scheda Impostazioni del repository in Ambienti.