Creación de flujos de trabajo confiables: salidas, contextos, desencadenadores y entregas entre trabajos

En esta unidad, aprenderá lo siguiente:

• Cómo transferir datos a través de flujos de trabajo mediante los datos en los resultados de pasos y tareas

• Uso de contextos de GitHub para la configuración y el control

• Diseño de flujos de trabajo con desencadenantes seguros y control defensivo de acceso

• Cómo asegurarse de que los flujos de trabajo solo se ejecutan en el contexto correcto

• Creación de flujos de trabajo confiables mediante datos estructurados y lógica de eventos

La autonomía debe diseñarse, no asumirse

Las diferentes tareas conllevan diferentes riesgos. Una buena arquitectura de agente usa la directiva para expresar diferentes niveles de autonomía en lugar de aplicar las mismas reglas en todas partes.

Un modelo de autonomía simple basado en riesgos podría tener este aspecto:

Implementación: aprobaciones de entorno para la ejecución de alto riesgo

Los entornos proporcionan un punto de control seguro para acciones de riesgo, como implementaciones y acceso a secretos protegidos. Si un entorno está configurado con revisores obligatorios, un trabajo dirigido a dicho entorno se pausará hasta que se conceda la aprobación.

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

Este diseño permite al agente preparar los cambios a la vez que impide que se ejecuten acciones que afectan a la producción de forma independiente.

Los resultados actúan como contratos del flujo de trabajo (diferencia entre resultados de pasos, resultados de trabajos y variables de entorno)

Cuando un flujo de trabajo genera información que deben consumir los pasos o trabajos posteriores, traten esos datos como un resultado explícito en lugar de "simples registros".

Enseñe y aplique estos principios:

• Los resultados de los pasos pasan los valores entre los pasos del mismo trabajo.

• Las salidas del trabajo transfieren valores entre trabajos (a través de dependencias entre trabajos).

• Las variables de entorno configuran el comportamiento en tiempo de ejecución, pero no deben reemplazar las salidas para el flujo de datos estructurado.

Modelo ilustrativo (mecánica mostrada, pero no en formato de examen)

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

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

Cuando se comparten trabajos, publique el resultado de un trabajo e incluya una referencia en este en un trabajo dependiente:

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

Contextos: GitHub frente a vars frente a env

Use el contexto adecuado para el propósito correcto:

• github.* → metadatos de eventos y decisiones en tiempo de ejecución ("qué desencadenó esta ejecución?")

• vars.* → valores de configuración administrados centralmente diseñados para reutilizarse

• env.* → variables de entorno a nivel de tarea y configuración en tiempo de ejecución

Desencadenamiento seguro y control defensivo

Aunque los flujos de trabajo estén diseñados para solicitudes de incorporación de cambios, los repositorios suelen tener varios activadores. Integre un control de defensa para que el modo "solo solicitud de incorporación de cambios" no se ejecute por error sin tener le contexto de una solicitud de incorporación de cambios.

Patrón general para enseñar:

• Aplique condiciones en los trabajos para garantizar que las acciones dependientes de la solicitud de incorporación de cambios solo se ejecuten cuando la ejecución esté vinculada a un evento de solicitud de incorporación de cambios.

Control de defensa para el modo de solo solicitud de incorporación de cambios

Aunque un flujo de trabajo esté diseñado para ejecutarse solo en solicitudes de incorporación de cambios, se puede activar también en otros eventos (por ejemplo, push, workflow_dispatch o schedule). Sin no se usan medidas de seguridad adicionales, los pasos específicos relacionados con una solicitud de incorporación de cambios, como los comentarios que se le añadan o la evaluación de cambios, pueden generar errores o responder de manera inesperada.

Para evitarlo, agregue una condición de nivel de trabajo que garantice que el flujo de trabajo solo se ejecute cuando esté asociado a una solicitud de incorporación de cambios.

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"

Conclusión clave: la confiabilidad del flujo de trabajo mejora cuando los planes y las señales se tratan como salidas estructuradas y protegidas por lógica compatible con eventos.

Tras esto, operará con los agentes de manera segura mediante ejecuciones auditables, controlando las herramientas y los secretos y creando barreras de protección basados en hooks y patrones de fiabilidad.