Creare flussi di lavoro affidabili: output, contesti, trigger e passaggi tra processi

In questa unità si apprenderà quanto segue:

• Come passare i dati nei flussi di lavoro usando output dei passaggi e delle attività

• Come usare i contesti di GitHub per la configurazione e il controllo

• Come progettare flussi di lavoro con trigger sicuri e controllo difensivo

• Come assicurarsi che i flussi di lavoro vengano eseguiti solo nel contesto corretto

• Come creare flussi di lavoro affidabili usando dati strutturati e logica degli eventi

L'autonomia deve essere progettata, non presunta

Diverse attività comportano rischi diversi. Un'architettura efficace dell'agente usa i criteri per esprimere livelli di autonomia diversi anziché applicare le stesse regole ovunque.

Un modello di autonomia semplice basato sul rischio potrebbe essere simile al seguente:

Implementazione: approvazioni dell'ambiente per l'esecuzione ad alto rischio

Gli ambienti forniscono un punto di controllo sicuro per azioni rischiose, ad esempio distribuzioni e accesso a segreti protetti. Se un ambiente è configurato con i revisori necessari, un processo destinato a tale ambiente verrà sospeso fino a quando non viene concessa l'approvazione.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
    steps:
      - run: echo "Deploying to production..."

Questa progettazione consente all'agente di preparare le modifiche impedendo al contempo di eseguire azioni che influiscano sull'ambiente di produzione in modo indipendente.

Gli output sono contratti del flusso di lavoro (output dei passaggi vs output dei lavori vs output dell'ambiente)

Quando un flusso di lavoro genera informazioni che i passaggi downstream o i processi devono utilizzare, considerarli come un output esplicito anziché "solo log".

Insegnare e applicare questi principi:

• Gli output delle fasi passano valori tra le fasi nello stesso processo.

• Gli output delle attività passano valori tra attività (tramite dipendenze delle attività).

• Le variabili di ambiente configurano il comportamento di runtime, ma non devono sostituire gli output per il flusso di dati strutturato.

Schema illustrativo (meccanica illustrata, ma non strutturato come un esame)

- id: generate_plan
  run: |
    echo "plan=high level steps..." >> "$GITHUB_OUTPUT"

- run: |
    echo "Plan: ${{ steps.generate_plan.outputs.plan }}"

Per la condivisione tra lavori, pubblicare un output di un lavoro e farvi riferimento da un lavoro dipendente:

jobs:
  plan:
    outputs:
      plan: ${{ steps.generate_plan.outputs.plan }}
    steps:
      - id: generate_plan
        run: echo "plan=..." >> "$GITHUB_OUTPUT"

  implement:
    needs: plan
    steps:
      - run: echo "Using plan: ${{ needs.plan.outputs.plan }}"

Contesti: GitHub vs vars vs env

Usare il contesto appropriato per lo scopo corretto:

• github.* → i metadati e le decisioni di runtime degli eventi ("cosa ha attivato l'esecuzione?")

• vars.* → valori di configurazione gestiti centralmente progettati per essere riutilizzati

• env.* → variabili di ambiente a livello di processo e configurazione di runtime

Attivazione sicura e controllo difensivo

Anche quando i flussi di lavoro sono progettati per richieste pull, spesso i repository hanno più trigger. Aggiungere un controllo difensivo in modo che il comportamento "solo PR" non venga eseguito accidentalmente senza un contesto di pull request.

Modello generale da insegnare:

• Usare le condizioni a livello di lavoro per garantire che le azioni dipendenti dalla pull request vengano eseguite solo quando l'esecuzione è strettamente associata a un evento di pull request.

Protezione difensiva per il comportamento solo pull request

Anche se un flusso di lavoro è destinato all'esecuzione solo per le richieste pull, può comunque essere attivato da altri eventi, ad esempio push, workflow_dispatch o pianificazione. Senza misure di sicurezza aggiuntive, passaggi specifici della richiesta pull, ad esempio commenti su una richiesta pull o valutazione delle modifiche, possono avere esito negativo o comportarsi in modo imprevisto.

È possibile evitare questo problema aggiungendo una condizione a livello di processo che garantisce l'esecuzione del flusso di lavoro solo quando è associata a una richiesta pull.

name: PR Validation

on:
  pull_request:
    branches: [ main ]
  workflow_dispatch: # allows manual runs, but still gated below

jobs:
  validate-pr:
    # Defensive gating: only run if this is actually a PR context
    if: github.event_name == 'pull_request'

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run tests
        run: npm test

      - name: Comment on PR
        run: echo "Validation complete"

Considerazioni chiave: l'affidabilità del flusso di lavoro migliora quando i piani e i segnali vengono considerati come output strutturati e sorvegliati dalla logica compatibile con gli eventi.

Successivamente, gestirete gli agenti in modo sicuro rendendo le esecuzioni verificabili, controllando strumenti e segreti, e creando guardrail basati su ganci e modelli di affidabilità.