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

Activadores y eventos de workflows

Explore diversos eventos que pueden activar sus workflows de GitHub Actions, como pushes, pull requests y eventos programados.

Activadores y eventos de workflows es una lección gratuita de CI/CD with GitHub Actions & DevOps Pipelines en CoddyKit. Esta es la lección 1 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.

¿Qué inicia un workflow?

Los workflows de GitHub Actions no se ejecutan por sí solos. ¡Necesitan una señal para comenzar! Esta señal se denomina trigger.

Los triggers son eventos específicos que indican a GitHub Actions: «¡Ha ocurrido algo! Es hora de ejecutar este workflow». Comprender los triggers es fundamental para automatizar eficazmente su proceso de desarrollo.

La palabra clave «on»

En el archivo de su workflow (un archivo .yml del directorio .github/workflows), puede definir los triggers mediante la palabra clave on.

Esta sección indica a GitHub Actions cuándo debe ejecutar el workflow. Puede especificar uno o varios eventos.

name: My First Triggered Workflow

on:
  push: # This workflow will run on every push event

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Run a simple command
        run: echo "Workflow triggered!"

Reaccionar a los pushes de código

El evento push es uno de los triggers más habituales. Se activa cada vez que se envía código al repositorio, ya sea mediante un commit nuevo o una fusión.

De forma predeterminada, un trigger push se ejecuta para todas las ramas.

on: push

jobs:
  greeting:
    runs-on: ubuntu-latest
    steps:
      - name: Say Hello
        run: echo "Code was pushed!"

Pushes dirigidos

Puede ajustar el trigger push para que se ejecute solo en ramas específicas o cuando se produzcan cambios en determinadas rutas de archivos. Esto ayuda a optimizar sus workflows.

  • branches: Se ejecuta solo cuando se hacen pushes en ramas con nombres específicos.
  • paths: Se ejecuta solo cuando se realizan cambios en archivos dentro de directorios especificados.
on:
  push:
    branches:
      - main
      - 'feature/*' # Glob pattern for feature branches
    paths:
      - 'src/**' # Only if changes in src/ directory

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Push to relevant branch/path detected!"

Automatizar las comprobaciones de pull requests

El evento pull_request se activa cuando se abre, sincroniza (se envían nuevos commits a la rama de la PR) o vuelve a abrirse una pull request.

Es ideal para ejecutar comprobaciones automatizadas, como pruebas, linting o revisiones de código, antes de fusionar los cambios en la base de código principal.

on: pull_request

jobs:
  pr_check:
    runs-on: ubuntu-latest
    steps:
      - name: PR opened/updated
        run: echo "A pull request was opened or updated!"

Acciones específicas de las PR

Puede ajustar aún más el trigger pull_request especificando types. Esto permite que su workflow reaccione únicamente a acciones específicas relacionadas con una pull request.

  • opened: Cuando se crea una pull request nueva.
  • synchronize: Cuando se envían nuevos commits a la rama de la PR.
  • reopened: Cuando se vuelve a abrir una pull request cerrada.
on:
  pull_request:
    types: [opened, synchronize, reopened] # Run only on these PR actions

jobs:
  pr_review:
    runs-on: ubuntu-latest
    steps:
      - run: echo "PR action: ${{ github.event.action }}"

Desencadenadores basados en el tiempo

El evento schedule permite ejecutar flujos de trabajo en momentos específicos mediante la sintaxis de cron. Es perfecto para generar informes diarios, realizar tareas de limpieza o llevar a cabo comprobaciones periódicas.

La sintaxis de cron utiliza cinco asteriscos que representan: minute hour day-of-month month day-of-week.

on:
  schedule:
    - cron: '0 0 * * *' # Run daily at midnight UTC
    - cron: '0 12 * * 1-5' # Run at 12 PM UTC, Mon-Fri

jobs:
  scheduled_task:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Scheduled workflow running!"

Ejecuciones manuales del flujo de trabajo

A veces es necesario ejecutar un flujo de trabajo manualmente, por ejemplo, para realizar un despliegue o una tarea de mantenimiento específica. El evento workflow_dispatch permite hacerlo.

Cuando este desencadenador está presente, aparece un botón «Run workflow» en la interfaz de GitHub para ese flujo de trabajo, lo que permite activarlo bajo demanda.

on: workflow_dispatch

jobs:
  manual_task:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This workflow was triggered manually!"

Más allá de lo básico

Aunque push, pull_request, schedule y workflow_dispatch son los más habituales, GitHub Actions ofrece muchos otros desencadenadores de eventos.

  • workflow_call: Para crear flujos de trabajo reutilizables.
  • repository_dispatch: Para activar flujos de trabajo desde sistemas externos mediante una llamada a una API.
  • Muchos más para eventos específicos de GitHub, como issues, release y fork.

Desafío sobre desencadenadores

Debe configurar un flujo de trabajo que genere automáticamente un informe semanal cada viernes a las 17:00 UTC, independientemente de que haya cambios en el código. ¿Qué evento desencadenador es el más adecuado para esta tarea?

Repaso de los desencadenadores

¡Excelente trabajo explorando los desencadenadores de GitHub Actions! Ha aprendido que los flujos de trabajo se inician mediante diversos eventos:

  • push: Para los cambios enviados al repositorio.
  • pull_request: Para las acciones relacionadas con las solicitudes de incorporación de cambios.
  • schedule: Para tareas recurrentes basadas en el tiempo mediante cron.
  • workflow_dispatch: Para la ejecución manual desde la interfaz o la API.

Elegir el desencadenador adecuado es el primer paso para crear pipelines de CI/CD eficaces y eficientes.

Preguntas frecuentes

¿La lección «Activadores y eventos de workflows» es gratis?

Sí — el texto completo de «Activadores y eventos de workflows» 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 «Activadores y eventos de workflows»?

Explore diversos eventos que pueden activar sus workflows de GitHub Actions, como pushes, pull requests y eventos programados. 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 1 de 4.

¿Cuánto tiempo toma la lección «Activadores y eventos de workflows»?

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. Activadores y eventos de workflows
  2. Ejecución de pruebas con GitHub Actions
  3. Linting y comprobaciones de calidad del código
  4. Almacenamiento en caché de dependencias para compilaciones más rápidas
← Volver a CI/CD with GitHub Actions & DevOps Pipelines