Betrouwbare werkstromen bouwen: uitvoer, contexten, triggers en hand-offs tussen taken
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.