0Pricing
CI/CD with GitHub Actions & DevOps Pipelines · Lección

Workflows entre repositorios

Aprenda a encadenar workflows entre distintos repositorios para gestionar dependencias y orquestar despliegues complejos.

Workflows entre repositorios es una lección gratuita de CI/CD with GitHub Actions & DevOps Pipelines en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de CI/CD with GitHub Actions & DevOps Pipelines, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de CI/CD with GitHub Actions & DevOps Pipelines incluye 4 lecciones en total.

Introducción a los flujos de trabajo entre repositorios

En el desarrollo de software moderno, las aplicaciones suelen estar formadas por varios componentes distribuidos en diferentes repositorios. Piense en microservicios, bibliotecas compartidas o configuraciones de despliegue independientes.

Orquestar flujos de trabajo entre estos repositorios distintos permite una mayor modularidad y separación de responsabilidades. En esta lección se explica cómo conseguirlo con GitHub Actions.

¿Por qué orquestar entre repositorios?

Tradicionalmente, los flujos de trabajo de GitHub Actions están limitados a un único repositorio. Pero ¿qué sucede si necesita:

  • ¿Compilar un artefacto en un repositorio y activar un despliegue en otro?
  • ¿Que un repositorio de configuración compartida active actualizaciones en varios repositorios de servicios?
  • ¿Aplicar políticas de seguridad gestionadas en un repositorio central al resto?

Los flujos de trabajo entre repositorios ofrecen la solución para estos escenarios complejos.

Conectar repositorios: `repository_dispatch`

GitHub Actions ofrece un tipo de evento especial llamado repository_dispatch. Este funciona como un webhook personalizado para sus repositorios de GitHub.

  • Un flujo de trabajo (el "emisor") envía una solicitud a la API de GitHub.
  • Otro flujo de trabajo (el "receptor"), ubicado en un repositorio diferente, escucha este evento específico.

Esto permite activar mediante programación flujos de trabajo en diferentes repositorios.

Configuración del flujo de trabajo receptor

Para recibir un evento repository_dispatch, es necesario configurar un flujo de trabajo en el repositorio de destino para que lo escuche. Esto se hace mediante la palabra clave on:.

Así podría ser un flujo de trabajo en repo-B:

name: Receive Dispatch Event

on:
  repository_dispatch:
    types: [my-custom-event]

jobs:
  process-event:
    runs-on: ubuntu-latest
    steps:
      - name: Log event payload
        run: |
          echo "Event type: ${{ github.event.action }}"
          echo "Payload: ${{ toJSON(github.event.client_payload) }}"

Comprender la configuración del receptor

En el ejemplo anterior:

  • on: repository_dispatch: indica a GitHub que escuche este evento.
  • types: [my-custom-event] especifica que este flujo de trabajo solo se ejecutará si el evento enviado tiene el tipo my-custom-event. Puede definir varios tipos.
  • github.event.action contendrá el tipo de evento (por ejemplo, my-custom-event).
  • github.event.client_payload contiene cualquier dato personalizado enviado con el dispatch.

Activar el evento: envío desde otro repositorio

Para activar un evento repository_dispatch, debe realizar una solicitud HTTP POST a la API de GitHub. Puede hacerlo mediante curl o la CLI de GitHub (gh cli) desde otro flujo de trabajo de GitHub Actions o desde un script.

Requisitos principales:

  • El propietario y el nombre del repositorio de destino.
  • Un type de evento que el flujo de trabajo receptor esté configurado para escuchar.
  • Un client_payload para incluir datos personalizados.
  • Un token de acceso personal de GitHub (PAT) con el alcance repo.

Ejemplo: enviar con `gh cli`

Este es un flujo de trabajo en repo-A que envía un evento a repo-B. Observe cómo usamos un secreto para el token y pasamos un client_payload.

name: Trigger Deploy Workflow

on:
  push:
    branches: [main]

jobs:
  dispatch:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Install GitHub CLI
        run: sudo apt-get update && sudo apt-get install gh -y

      - name: Dispatch event to repo-B
        env:
          GH_TOKEN: ${{ secrets.CROSS_REPO_PAT }}
        run: |
          gh api \
            --method POST \
            -H "Accept: application/vnd.github.v3+json" \
            /repos/YOUR_ORG/repo-B/dispatches \
            -f event_type='my-custom-event' \
            -f client_payload='{"ref":"${{ github.ref }}", "sha":"${{ github.sha }}"}'

Proteger el acceso entre repositorios

El GITHUB_TOKEN predeterminado que se proporciona a un flujo de trabajo está limitado al repositorio en el que se ejecuta dicho flujo. Para activar eventos en *otro* repositorio, necesita un token con permisos más amplios.

  • Use un token de acceso personal (PAT) con el alcance repo.
  • Almacene este PAT como un secreto del repositorio (por ejemplo, CROSS_REPO_PAT) en el repositorio que activa el evento.
  • Nunca incluya los PAT directamente en los archivos de flujo de trabajo.

Pasar datos personalizados con `client_payload`

client_payload es un objeto JSON que puede incluir al enviar un evento. Es fundamental para pasar contexto o datos del flujo de trabajo que activa el evento al flujo de trabajo receptor.

Ejemplos de datos que podría pasar:

  • El SHA de la confirmación o el nombre de la rama que activó la compilación.
  • Un destino de entorno (por ejemplo, "staging", "production").
  • El número de versión de un artefacto que se va a implementar.

Recuerde: client_payload aparece en los registros del flujo de trabajo, por lo que debe evitar incluir información confidencial.

Comprobación rápida de los flujos entre repositorios

Ha aprendido a orquestar flujos de trabajo entre distintos repositorios de GitHub. Comprobemos si comprende los componentes principales.

Recapitulación: orquestación entre repositorios

¡Ha aprendido correctamente a implementar flujos de trabajo entre repositorios mediante repository_dispatch!

  • Por qué: Para gestionar dependencias y orquestar implementaciones complejas en varios repositorios.
  • Cómo: Un flujo de trabajo «emisor» realiza una llamada a la API de GitHub, lo que activa un flujo de trabajo «receptor» en otro repositorio.
  • Elemento clave: El tipo de evento repository_dispatch y los types correspondientes en el flujo de trabajo receptor.
  • Datos: Use client_payload para pasar información no confidencial entre flujos de trabajo.
  • Seguridad: Use siempre un PAT con el alcance repo, almacenado como secreto, para acceder a otros repositorios.

Esta potente función permite crear canalizaciones de CI/CD muy flexibles y desacopladas.

Preguntas frecuentes

¿La lección «Workflows entre repositorios» es gratis?

Sí — el texto completo de «Workflows entre repositorios» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de CI/CD with GitHub Actions & DevOps Pipelines, actualiza a CoddyKit PRO. El curso de CI/CD with GitHub Actions & DevOps Pipelines incluye 4 lecciones en total.

¿Qué aprenderé en «Workflows entre repositorios»?

Aprenda a encadenar workflows entre distintos repositorios para gestionar dependencias y orquestar despliegues complejos. Practicas CI/CD with GitHub Actions & DevOps Pipelines con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar CI/CD with GitHub Actions & DevOps Pipelines?

No se requiere experiencia previa. CI/CD with GitHub Actions & DevOps Pipelines en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Workflows entre repositorios»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de CI/CD with GitHub Actions & DevOps Pipelines?

Sí. Cada lección de CI/CD with GitHub Actions & DevOps Pipelines incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. CI/CD para monorepositorios
  2. Workflows entre repositorios
  3. Gestión centralizada de workflows
  4. Filtrado por rutas y compilaciones selectivas
← Volver a CI/CD with GitHub Actions & DevOps Pipelines