Betrouwbare werkstromen bouwen: uitvoer, contexten, triggers en hand-offs tussen taken

Voltooid

In deze les leert u het volgende:

  • Gegevens doorgeven via werkstromen met behulp van stap- en taakuitvoer

  • GitHub contexten gebruiken voor configuratie en beheer

  • Werkstromen ontwerpen met veilige triggers en defensieve poorten

  • Ervoor zorgen dat werkstromen alleen worden uitgevoerd in de juiste context

  • Betrouwbare werkstromen bouwen met gestructureerde gegevens en gebeurtenislogica

Autonomie moet worden ontworpen, niet verondersteld

Verschillende taken dragen verschillende risico's met zich mee. Een goede agentarchitectuur maakt gebruik van beleid om verschillende autonomieniveaus uit te drukken in plaats van overal dezelfde regels toe te passen.

Een eenvoudig op risico's gebaseerd autonomiemodel kan er als volgt uitzien:

Taaktype Voorbeeldpaden Risiconiveau Autonomieontwerp
Low docs/, opmaak Low Samenvoegen kan worden geautomatiseerd met behulp van GitHub automerge nadat de vereiste controles (en beoordelingen, indien geconfigureerd) zijn geslaagd.
Gemiddeld src/, afhankelijkheidsstoten Gemiddeld Pr vereist + controles + ten minste één beoordeling
Hoog infra/, .github/workflows/ Hoog CODEOWNERS + meerdere beoordelingen + strengere regelsets
Kritiek met productie worden instellingen, geheimen geïmplementeerd Kritiek agent bereidt zich voor, maar kan niet uitvoeren

Implementatie: omgevingsgoedkeuringen voor uitvoering met een hoog risico

Omgevingen bieden een sterk controlepunt voor riskante acties, zoals implementaties en toegang tot beveiligde geheimen. Als een omgeving is geconfigureerd met de vereiste revisoren, wordt een taak die gericht is op die omgeving, onderbroken totdat goedkeuring is verleend.

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

Dit ontwerp stelt de agent in staat om wijzigingen voor te bereiden, terwijl het voorkomt dat deze zelfstandig acties uitvoert die invloed hebben op de productie.

Uitvoer zijn werkstroomcontracten (stapuitvoer versus taakuitvoer versus env)

Wanneer een werkstroom informatie genereert die downstream-stappen of taken moeten gebruiken, moet u deze gegevens beschouwen als een expliciete uitvoer in plaats van enkel logbestanden.

Leer en pas deze principes toe:

  • De uitvoer van stappen geeft waarden door tussen stappen in dezelfde taak.

  • Taakuitvoer geeft waarden door tussen taken (via taakafhankelijkheden).

  • Omgevingsvariabelen configureren runtimegedrag, maar moeten geen uitvoer vervangen voor gestructureerde gegevensstroom.

Illustratief patroon (mechanica weergegeven, maar niet in de vorm van een examen):

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

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

Voor het delen van taken publiceert u een taakuitvoer en verwijst u ernaar vanuit een afhankelijke taak:

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

Contexten: GitHub vs vars vs env

Gebruik de juiste context voor het juiste doel:

  • github.* → gebeurtenismetagegevens en runtimebeslissingen ('wat heeft deze uitvoering geactiveerd?')

  • vars.* → centraal beheerde configuratiewaarden die zijn ontworpen om opnieuw te worden gebruikt

  • env.* → omgevingsvariabelen op taakniveau en runtimeconfiguratie

Veilig activeren en defensieve schakeling

Zelfs wanneer workflows zijn ontworpen voor pull requests, hebben repositories vaak meerdere triggers. Voeg defensieve gating toe, zodat 'alleen-PR'-gedrag niet per ongeluk wordt uitgevoerd zonder een PR-context.

Algemeen patroon om te leren:

  • Gebruik voorwaarden op taakniveau om ervoor te zorgen dat pull-request-afhankelijke acties alleen worden uitgevoerd wanneer de uitvoering is gekoppeld aan een pull-request gebeurtenis.

Defensieve gating voor alleen-pull-aanvraaggedrag

Zelfs als een werkstroom alleen voor pull-aanvragen moet worden uitgevoerd, kan deze nog steeds worden geactiveerd door andere gebeurtenissen (bijvoorbeeld pushen, workflow_dispatch of plannen). Zonder extra beveiliging kunnen pr-specifieke stappen, zoals opmerkingen bij een pull-aanvraag of het evalueren van wijzigingen, mislukken of werken ze onverwacht.

U kunt dit voorkomen door een voorwaarde op taakniveau toe te voegen die ervoor zorgt dat de werkstroom alleen wordt uitgevoerd wanneer deze is gekoppeld aan een pull-aanvraag.

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"

Belangrijke leerpunten: de betrouwbaarheid van werkstromen verbetert wanneer plannen en signalen worden behandeld als gestructureerde uitvoer en worden bewaakt door gebeurtenisbewuste logica.

Vervolgens gaat u agents veilig bedienen door uitvoering controleerbaar te maken, tools en gevoelige gegevens te beheren en op hooks gebaseerde veiligheidsmarges en betrouwbaarheidsstructuren te bouwen.