Skapa tillförlitliga arbetsflöden – utdata, kontexter, utlösare och överlämningar mellan jobb

Slutförd

I den här lektionen får du lära dig:

  • Så här skickar du data via arbetsflöden med hjälp av steg- och jobbutdata

  • Så här använder du GitHub kontexter för konfiguration och kontroll

  • Så här utformar du arbetsflöden med säkra utlösare och skyddande kontrollpunkter

  • Så här ser du till att arbetsflöden endast körs i rätt kontext

  • Skapa tillförlitliga arbetsflöden med strukturerad data och händelselogik

Autonomi måste utformas, inte antas

Olika uppgifter medför olika risker. En bra agentarkitektur använder principer för att uttrycka olika autonominivåer i stället för att tillämpa samma regler överallt.

En enkel riskbaserad autonomimodell kan se ut så här:

Aktivitetstyp Exempelsökvägar Risknivå Design av autonomi
Low docs/, formatering Low sammanfogning kan automatiseras med GitHub automerge efter att nödvändiga kontroller (och granskningar, om de har konfigurerats) har godkänts
Medium src/, beroendeuppdateringar Medium PR krävs + kontroller + minst en granskning
Hög infra/, .github/workflows/ Hög CODEOWNERS + flera recensioner + striktare regeluppsättningar
Kritisk production distribuerar inställningar, hemligheter Kritisk miljögodkännanden; agenten förbereder men kan inte utföra

Implementering: miljögodkännanden för högriskkörning

Miljöer ger en stark kontrollpunkt för riskfyllda åtgärder som distributioner och åtkomst till skyddade hemligheter. Om en miljö har konfigurerats med nödvändiga granskare pausas ett jobb som riktar sig mot miljön tills godkännande har beviljats.

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

Med den här designen kan agenten förbereda ändringar samtidigt som den inte kan utföra åtgärder som påverkar produktionen oberoende av varandra.

Utdata är arbetsflödeskontrakt (stegutdata jämfört med jobbutdata jämfört med env)

När ett arbetsflöde genererar information som underordnade steg eller jobb måste använda behandlar du dessa data som explicita utdata i stället för "bara loggar".

Lär ut och tillämpa följande principer:

  • Utdata från steg skickar värden mellan steg i samma jobb.

  • Jobbutdata skickar värden mellan jobb (via jobbberoenden).

  • Miljövariabler konfigurerar körningsbeteende men bör inte ersätta utdata för strukturerade dataflöden.

Illustrativt mönster (mekanik som visas, men inte examensformad):

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

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

För delning mellan jobb publicerar du ett jobbutdata och refererar till det från ett beroende jobb:

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 }}"

Kontexter: GitHub vs vars vs env

Använd rätt kontext för rätt syfte:

  • github.* → händelsemetadata och körningsbeslut ("vad utlöste den här körningen?")

  • vars.* → centralt hanterade konfigurationsvärden som är utformade för återanvändning

  • env.* → miljövariabler på jobbnivå och körningskonfiguration

Säker aktivering och defensiv gränssnittstyrning

Även när arbetsflöden är utformade för PR:er har lagringsplatser ofta flera utlösare. Lägg till defensiv gating så att "endast PR"-beteende inte av misstag körs utan en PR-kontext.

Allmänt mönster att lära ut:

  • Använd villkor på jobbnivå för att säkerställa att PR-beroende aktiviteter endast körs när körningen är associerad med en PR-händelse.

Defensiv gating för endast pull-begärandebeteende

Även om ett arbetsflöde endast är avsett att köras för pull-begäranden kan det fortfarande utlösas av andra händelser (till exempel push, workflow_dispatch eller schema). Utan ytterligare skydd kan steg som är specifika för PR, såsom att kommentera på en pull request eller utvärdera ändringar, misslyckas eller bete sig oväntat.

Du kan förhindra detta genom att lägga till ett villkor på jobbnivå som säkerställer att arbetsflödet endast körs när det är associerat med en pull-begäran.

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"

Viktig information: Arbetsflödets tillförlitlighet förbättras när planer och signaler behandlas som strukturerade utdata och skyddas av händelsemedveten logik.

Därefter kommer du att använda agenter på ett säkert sätt genom att göra körningar granskningsbara, kontrollera verktyg och hemligheter och skapa hooks-baserade skyddsräcken och tillförlitlighetsmönster.