Skip to main content
Invece di scrivere script shell per installare strumenti, puoi fare riferimento direttamente a GitHub Actions nella sezione initialize del tuo blueprint. Devin scarica ed esegue l’action durante la build dello snapshot, proprio come i runner CI di GitHub eseguono i passaggi delle action. Questo è particolarmente utile per le action di configurazione dei linguaggi come setup-python, setup-node e setup-go, che gestiscono automaticamente la gestione delle versioni e la configurazione del PATH.

​
Sintassi

Aggiungi un passaggio uses alla sezione initialize del tuo blueprint:
Un passaggio deve specificare run (un comando shell) oppure uses (un’azione), non entrambi.
I passaggi uses non sono supportati in maintenance. Un passaggio maintenance con uses fa fallire la build dello snapshot con l’errore 'uses' steps are not supported in maintenance sections ... Actions can only run during initialize. Inserisci le action in initialize e limita maintenance ai passaggi run. Anche i passaggi post-build a livello di organizzazione ed enterprise possono usare le action.

​
Formato di riferimento per le azioni

Il prefisso github.com/ e il suffisso @<ref> sono entrambi obbligatori. Il ref è in genere un tag di versione come v5. Esempi:

​
Passare input

Usa il campo with per passare input alla action. Tutti i valori vengono trattati come stringhe, in linea con il comportamento di GitHub Actions:
Racchiudi sempre tra virgolette i numeri di versione nei valori with. YAML interpreta 3.10 senza virgolette come il numero in virgola mobile 3.1, che non è ciò che vuoi. Scrivi invece python-version: "3.10".

​
Impostare le variabili d’ambiente

Usa il campo env per impostare variabili d’ambiente nell’ambito di un singolo passaggio della action:
Le variabili d’ambiente impostate da una action (tramite GITHUB_ENV o GITHUB_PATH) vengono propagate automaticamente ai passaggi successivi del blueprint.

​
Esempi

​
Progetto Python con una versione specifica

​
Progetto multilingue

​
Combinare azioni e comandi shell

Azioni e comandi shell possono essere combinati liberamente nella stessa sezione:

​
Progetto Java con Gradle

​
Actions vs. script shell

Non è necessario usare le actions: anche i semplici comandi shell funzionano benissimo. Le actions sono comode quando lo script shell equivalente sarebbe lungo o soggetto a errori.

​
Come funziona

Quando Devin incontra un passaggio uses durante una build dello snapshot:
  1. Scarica la repository della action (clone shallow del ref bloccato)
  2. Legge i metadati action.yml della action per determinare il tipo di action (runs.using) e i punti di ingresso
  3. Crea l’ambiente di esecuzione con le variabili INPUT_*, GITHUB_* e RUNNER_*
  4. Esegue la action in base al suo tipo:
    • Action Node.js — esegue lo script pre (se definito), poi main
    • Action composite — esegue in ordine ogni passaggio in runs.steps, inclusi i passaggi annidati run e uses
    • Action Docker — crea l’image dal Dockerfile della action (oppure scarica un’image docker://), quindi esegue il container, incluso pre-entrypoint se definito
  5. Propaga gli effetti collaterali: tutte le voci scritte dalla action in GITHUB_PATH o GITHUB_ENV vengono applicate ai passaggi successivi del blueprint
Le action vengono eseguite al di fuori di un vero flusso di lavoro GitHub. Le variabili di contesto come github.repository vengono popolate con valori fittizi. Le action che richiedono accesso in tempo reale all’API di GitHub (ad es. commentare le pull request (PR) o creare release) non funzioneranno nei blueprint.

​
Limitazioni

  • Tipi di action supportati — I blueprint supportano questi tipi di action (runs.using):
  • Non in maintenance — I passaggi uses vengono eseguiti in initialize e post-build, ma non possono essere eseguiti in maintenance. Vedi Sintassi.
  • Nessun ciclo di vita post — Devin esegue i passaggi pre e main (e il pre-entrypoint di un’action Docker), ma salta i passaggi di pulizia post (post e post-entrypoint), poiché le build vengono eseguite in VM temporanee.
  • Contesto GitHub fittizio — Le action che dipendono da chiamate API di GitHub, dai dati degli eventi del flusso di lavoro o dal contesto del repository potrebbero non funzionare correttamente, perché questi valori sono segnaposto nell’ambiente di build.
  • Blocca le versioni — Fai sempre riferimento a un tag di versione specifico (ad es. @v5) anziché al nome di un branch, per ottenere build riproducibili.