Créer des flux de travail fiables - sorties, contextes, déclencheurs et transferts inter-tâches

Dans cette unité, vous allez apprendre :

• Comment transmettre des données à travers des flux de travail au moyen des sorties d’étape et de tâche

• Comment utiliser des contextes GitHub pour la configuration et le contrôle

• Guide pratique pour concevoir des flux de travail avec des déclencheurs sécurisés et un gating défensif

• Comment garantir que les flux de travail s’exécutent uniquement dans le contexte correct

• Comment créer des flux de travail fiables à l’aide de données structurées et d’une logique d’événement

L’autonomie doit être conçue, non supposée

Différentes tâches présentent différents risques. Une bonne architecture d’agent utilise une stratégie pour exprimer différents niveaux d’autonomie plutôt que d’appliquer les mêmes règles partout.

Un modèle d’autonomie simple basé sur les risques peut ressembler à ceci :

Implémentation : approbations d’environnement pour l’exécution à haut risque

Les environnements fournissent un point de contrôle fort pour les actions risquées telles que les déploiements et l’accès aux secrets protégés. Si un environnement est configuré avec les réviseurs requis, un travail ciblant cet environnement s’interrompt jusqu’à ce que l’approbation soit accordée.

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

Cette conception permet à l’agent de préparer les modifications tout en l’empêchant d’exécuter des actions ayant un impact sur la production indépendamment.

Les sorties sont des contrats de workflow (sorties d'étape contre sorties de travail contre environnement)

Lorsqu'un workflow génère des informations que les étapes ou travaux en aval doivent consommer, traitez ces données comme une sortie explicite plutôt que « juste des fichiers journaux ».

Enseignez et appliquez ces principes :

• Les sorties d'étape transfèrent des valeurs entre les étapes du même travail.

• Les sorties de travail transmettent des valeurs entre les travaux (via les dépendances de travail).

• Les variables d’environnement configurent le comportement d’exécution, mais ne doivent pas remplacer les sorties pour le flux de données structuré.

Motif illustrant (mécanique illustrée, mais pas en forme d’examen) :

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

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

Pour le partage entre tâches, publiez un résultat de tâche et faites-y référence à partir d’une tâche dépendante :

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

Contextes : GitHub vs vars vs env

Utilisez le contexte approprié à des fins appropriées :

• github.* → les métadonnées d’événement et les décisions d’exécution (« qu’est-ce qui a déclenché cette exécution ? »)

• vars.* → valeurs de configuration gérées de manière centralisée conçues pour être réutilisées

• env.* → variables d’environnement au niveau du travail et configuration du runtime

Déclenchement sécurisé et filtrage défensif

Même lorsque les flux de travail sont conçus pour les pull requests, les référentiels ont souvent plusieurs déclencheurs. Ajoutez un contrôle de sécurité pour que le comportement réservé aux PR ne s'exécute pas accidentellement sans contexte de demande de tirage.

Modèle général à enseigner :

• Utilisez des conditions au niveau de l'emploi pour garantir que les actions dépendantes des PR ne s'exécutent que lorsque l'exécution est liée à un événement de PR.

Gating défensif pour un comportement basé uniquement sur les pull requests

Même si un flux de travail est destiné à s'exécuter uniquement pour les pull requests, il peut toujours être déclenché par d'autres événements (par exemple, push, workflow_dispatch, ou schedule). Sans protection supplémentaire, les étapes spécifiques aux pull requests, tels que commenter une pull request ou évaluer les modifications, pourraient échouer ou avoir un comportement inattendu.

Vous pouvez éviter cela en ajoutant une condition au niveau de la tâche qui garantit que le flux de travail s’exécute uniquement lorsqu’il est associé à une pull request.

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"

Clé à prendre en compte : la fiabilité du flux de travail s’améliore lorsque les plans et les signaux sont traités comme des sorties structurées et gardés par la logique prenant en charge les événements.

Ensuite, vous allez exploiter les agents en toute sécurité en rendant les exécutions auditables, en contrôlant les outils et les secrets, et en créant des garde-fous fondés sur des hooks et des modèles de fiabilité.