No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

No se trata de lo que quieres comprar, sino de quién quieres ser. Invierte en tu educación con el precio especial

Antes: $249

Currency
$209

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscríbete

Termina en:

12 Días
10 Hrs
58 Min
11 Seg
Curso de GitHub Actions

Curso de GitHub Actions

Juan José Torres

Juan José Torres

Triggers: eventos que inician workflows en GitHub Actions

6/18
Recursos

GitHub Actions nos ofrece una amplia lista de 'triggers' que pueden lanzar nuestros 'workflows'. Algunos de los más comunes incluyen 'push', 'pull request', 'issue', 'issue comment', 'workflow dispatch', y 'schedule'.

¿Cómo funciona el 'trigger' de 'push'?

Cuando haces 'push' de un nuevo 'commit' en alguna rama que tú definas, puedes activar un 'workflow'.

Esta acción también se puede configurar para todas las ramas y puede especificar a qué ramas afectará mediante la opción 'branches'. Y con la opción 'paths' puedes especificar qué archivos deben modificarse para que el 'workflow' se active.

¿Cómo se utiliza el 'trigger' de 'pull request'?

El 'trigger' 'pull request' ofrece características muy similares al de 'push'. Esto incluye 'branches' y 'paths', y también incluye 'types', que te permite especificar sobre qué acciones sobre 'pull request' quieres que se active.

¿Cómo manejar la opción 'issues' y 'issue comment'?

El 'trigger' 'issues' funciona de manera similar al 'pull request', y tiene los mismos 'types'. Sin embargo, 'issue comment' funciona cuando se hacen comentarios nuevos sobre un 'issue' o 'pull request', y también puedes especificar si la acción se ejecuta solo en los comentarios de un 'pull request'.

¿Cómo lanzar 'workflows' de forma manual con 'workflow dispatch'?

El 'workflow dispatch' te permite lanzar un 'workflow' de forma manual y agregar los parámetros que desees. Puedes crear 'inputs', y estos pueden ser de diferentes tipos, como una elección, un boolean, o un string.

¿Cómo programar eventos con el 'schedule'?

Finalmente, el 'trigger' 'schedule' te permite programar eventos que ocurran a intervalos regulares. Puedes especificar los minutos, la hora, el día del mes, el mes, y el día de la semana.

¿Cómo puedes practicar la creación de 'workflows' basados en 'triggers'?

Para practicar la creación de 'workflows', te recomiendo que crees un nuevo archivo 'workflow' que use al menos tres de los 'triggers' que acabamos de explicar.

Comparte tus soluciones en la sección de comentarios y compáralas con las de otros. En la próxima entrega veremos más sobre cómo usar las expresiones en GitHub Actions. ¡Esperamos verte allí!

Aportes 7

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Push

Push se entiende cuando mandamos al repositorio remoto las actualizaciones del repositorio local.

Este script acaparará el trigger push mientras suceda en los branches main o releases/** (cualquier rama con nombre release o que nazca a partir de este nombre) y solo se tendrá en cuenta si se han modificado archivos de formato .js.

on: #Acaparará los triggers de este workflow
	push: #El tipo de trigger: push
		branches: #Las ramas en las que se activará el workflow
			- 'main' #Se activará si se hace push en la rama main
			- 'releases/**' #O en la rama releases y derivados
		paths: #Serán las rutas que se tendrán en cuenta para activar el workflow
			- '**.js' #Todos los archivos .js en el repositorio

Pull Request

El Pull Request será la petición de mergear una rama aislada con otra rama (generalmente principal).

Este script se activará por un PR, específicamente en el momento de abrirlo y etiquetarlo (opened y labeled), seguirá el resto de reglas que el push.

on: #Acaparará los triggers de este workflow
	pull_request: #El tipo de trigger: pr
		types: #Los estados que activarán el trigger
			- [opened, labeled] #Tomará los estados del PR
		branches: #Las ramas en las que se activará el workflow
			- 'releases/**' #En la rama releases y derivados
		paths: #Serán las rutas que se tendrán en cuenta para activar el workflow
			- '**.js' #Todos los archivos .js en el repositorio

Issues

Los issues son foros donde se anuncian difuncionalidades del código por parte de la comunidad o los propios developers.

Tiene la misma lógica de los PR, sin embargo, los types cambiarán.

on: #Acaparará los triggers de este workflow
	issues: #El tipo de trigger: issues
		types: #Los estados que activarán el trigger
			- [opened, edited, closed]

Issue Comment

Cuando se generen comentarios en un Issue o un PR se activará este trigger.

Tendremos 2 casos, el primero donde se ejecutará un issue comment, y el segundo donde se ejecutará en un PR comment.

En este caso cada que se cree o elimine un comentario de un Issue se activará y correrá el workflow.

on:
	issue_comment: 
		types:  [created, deleted]

En este segundo ejemplo también trabajaremos por issue_comment, sin embargo, añadiremos un job que verificará que estamos sobre un pull request con el condicional dado, si es verdad, podrá continuar.

on: issue_comment
jobs:
	pr_commented:
		name : PR comment
		if : ${{ github.event.issue.pull_request }}

Workflow dispatch

Los Workflow dispatch son Workflows de activación manual, estos poseen la característica de poder setear inputs, los configuraremos dentro del archivo YAML.

Este Workflow contendrá 3 variables a ingresar las cuales serán alerta, tags y enviroment, serán contenidas por la etiqueta inputs y en cada una especificaremos sus características. La primera tendrá una descripción, será obligatoria, tendrá medio como valor por defecto y será de tipo choice (las opciones serán alto, medio o bajo). Los otros 2 casos son parecidos, donde tags será un boolean opcional y enviroments un string obligatorio.

on: 
	workflow_dispatch:
		inputs:
			alerta:
				description : 'Nivel'
				required : true
				default : medio
				type : choice
				option :
				- bajo
				- medio
				- alto

			tags:
				description : 'Opcional'
				required : false
				****type : boolean

			enviroment:
				description : 'Objetivo'
				required : true
				type : string

Schedule

Los schedules son un tipo de trigger que se activará automáticamente por una regla de tiempo.

on:
	schedule:
		- cron : '30 5,17 * * *'

Puedes notar que hay 2 valores puestos (30 - 5,17) y 3 asteriscos, esta es una notación de cronograma que indicará valores a nivel de tiempo.

[Minuto, Hora, Dia del mes, Mes, Día de la semana]

Minuto (0 - 59)
Hora (0 - 23) 
Día del mes (1 - 31) 
Mes (1 - 12 o JAN - DEC)
Día de la semana ( 0 - 6 o SUN - SAT)

Si el valor tiene un asterisco significa que será cíclico, si tiene coma significa que agrupará 2 valores

Por lo que nuestro ‘30 5,17 * * *’ significa a las 5:30AM y 5:30PM todos los días todos los meses del año.

esto puede ser util para cuando armar el crontab <https://crontab.guru/>
\[listado-trigger-events]\(https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows) de github.

Reto del Workflow file Trigger 😄

name: Triggers
run-name: Praxis 3 Triggers!
on:
  push:  #PUSH
    branches: ['main', 'aprendiendo-**']
    paths: ['**.yml']
  
  pull_request:  # PR
    types: [opened, labeled]
    branches: ['main', 'aprendiendo-**']
    paths: ['**.yml']
    
  schedule:  # SCHEDULE
    - cron: '59 23 * * SUN'
  
  workflow_dispatch:  # WORKFLOW_DISPATCH

jobs:
  job-t:
    runs-on: ubuntu-latest
    steps:
      - name: Clonar Repo en el Runner
        uses: actions/checkout@v4
      
      - name: Setup Python Environment
        uses: actions/setup-python@v5
        with:
          python-version: '3.10'
      
      - name: Define Variable IP
        id: ip
        uses: haythem/[email protected]
        
      - name: Define Variable USERNAME   
        run: echo "USERNAME=${{ github.actor }}" >> $GITHUB_ENV
      
      - name: Run multi-line script
        run: |
          echo "Hello from IP: ${{ steps.ip.outputs.ipv4 }}"
          python hola-mundo.py
    
          
Dejo mi ejercicio que hice en java: ```js name: trigger practice run-name: Estoy aprendiendo los trigger on: push: branches: - main pull_request: types: [opened, labeled] workflow_dispatch: inputs: alerta: description: 'Nivel' required: true default: medio type: choice options: - bajo - medio - alto tags: description: 'Opcional' required: true type: string jobs: hola-mundo: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: definir variable run: echo "USERNAME=${{ github.actor }}" >> $GITHUB_ENV - name: correr script con variables run: java Main.java ```
name: clase triggers
on: [push, status, create]
jobs: 
  run-java:
    runs-on: ubuntu-latest
    steps: 
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Compile and run Java Code
        run: |
          javac Entrada.java
          java Entrada 
name: hello-world # Nombre del workflow
run-name: mi primer workflow!
on: [push] # Trigger (evento) que lo activara (cuando se corra git push ... correra este trigger)
jobs: # Definición de los jobs
  hello-world: # Nombre del job
    runs-on: ubuntu-latest # Servidor en la que correra
    steps: # Lista de steps del job hello-world
      - uses: actions/checkout@v3
      - uses: denoland/setup-deno@v1
        with:
          deno-version: v1.x
      - name: Setup variable
        run: echo "USERNAME=${{github.actor}}" >> $GITHUB_ENV
      - name: Run main.ts
        run: deno run -A main.ts