Workflow y Eventos

Vamos a sumergirnos un poco más en los eventos que pueden ser el disparador para un workflow. Es posible filtrar los eventos de un push en lugar de mantenerlo genérico siendo activado por cualquier push.

• Filtrado de eventos
• tipos de eventos

Tenemos varios tipos de eventos que activan los workflows, siendo la mayoría de ellos referentes al repositorio.

Documentación para los tipos de trigger

Vamos a explorar un poco de los principales y aprender cómo pueden ser usados en los workflows y cuándo estos eventos son ocasionados.

Uno de los más importantes eventos es el push.

Podemos hacer un filtro en el evento de push para que solamente ejecute el workflow en una situación específica, no en cualquier evento de push del repositorio. Cada tipo de evento posee especificaciones para un control granular. Siempre consulta la documentación cuando sea necesario.

Existen eventos que poseen un tipo de actividad dentro de este evento que podemos usar, pero no están presentes en todos los tipos de eventos, solamente en algunos. El evento pull_request posee varios tipos de actividad, por ejemplo opened, closed, edited, etc. En el caso del push, no tenemos ese tipo de actividad, usamos solamente filtros.

push	pull_request

Si lees la documentación del pull_request verás que si no especificamos los tipos el valor por defecto usado son opened, synchronize y reopened.

name: Events Demo 1
on:
  # cada vez que un pull request sea abierto será ejecutado
  pull_request:
    types:
      - opened
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Output event data
        run: echo "${{ toJSON(github.event) }}"
      - name: Get code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Test code
        run: npm run test
      - name: Build code
        run: npm run build
      - name: Deploy project
        run: echo "Deploying..."

Una vez que declaramos los tipos de evento del pull_request para solamente opened, si editamos no disparará nuevamente el workflow.

Vamos ahora a añadir el push para ejecutar solamente en algunas ramas.

on:
  push:
    branches:
      - main
      # Usamos el * para permitir variaciones en los nombres
      # Permite cualquier nombre con el prefijo dev- y no use /
      - 'dev-*' ninguna /
      # Dos * permiten que / sean caracteres válidos ejemplo feat/new / feat/new/button
      - 'feat/**'

También no queremos que sea para cualquier pull request, necesitan estar en las ramas de arriba, entonces vamos a alterar.

on:
  push:
    branches:
      - main
      # Usamos el * para permitir variaciones en los nombres
      # Permite cualquier nombre con el prefijo dev- y no use /
      - 'dev-*'
      # Dos * permiten que / sean caracteres válidos ejemplo feat/new / feat/new/button
      - 'feat/**'
  pull_request:
    types:
      - opened
    branches:
      - main
      - 'dev-*'
      - 'feat/**'
  workflow_dispatch:

También puedes filtrar basándote en las rutas de los archivos con el filtro path presente en el push y en el pull request. Esto permite que digas básicamente que deseas ejecutar un workflow si un push o un pull_request altera archivos en una ruta específica o con paths-ignore si altera cualquier cosa, excepto archivos en una carpeta específica.

No queremos ejecutar cuando pongamos más workflows o alteremos la documentación o el .gitignore por ejemplo.

on:
  push:
    branches:
      - main
      - 'dev-*'
      - 'feat/**'
    # Ignora cambios en las rutas de abajo
    paths-ignore:
      - '.github/workflows/*'
      - '.gitignore'
      - docs # Una carpeta de documentación por ejemplo
  pull_request:
    types:
      - opened
    branches:
      - main
      - 'dev-*'
      - 'feat/**'
  workflow_dispatch:

Vamos a imaginar que alguien hizo un fork de tu proyecto público hizo alguna alteración en el código y pidió un pull request para el proyecto. Caería en el evento pull_request del tipo opened para la rama main y debería ejecutar un workflow. Sin embargo está viniendo de terceros y quedará con la exclamación.

Entrando en el workflow tenemos que necesita una aprobación del mantenedor del proyecto.

Si cualquiera pudiera estar haciendo pull request para tu repositorio generar una cuenta absurdamente alta para pagar, ¿ya has pensado en eso?

Pull requests basadas en forks no activan un workflow aunque técnicamente debería. Cuando aprobamos la primera vez el pull request de alguien los próximos serán aceptados y ejecutará como esperado. Si es alguien que realmente colabore con el repositorio principal tal vez sea interesante ponerlo como colaborador dentro del repositorio y evitar forks externos.

Evitando Workflows

Vamos a imaginar que estamos creando el README.md de un repositorio, alguna documentación o comentando algún código. Si damos un push los cambios generarán un workflow, podemos simplemente ignorarlos colocando un mensaje en el commit. No tiene sentido ejecutar un workflow enorme si no estamos alterando lo que debería o subiendo más archivos extras que no forman parte del sistema.

git commit -m "Tu mensaje [skip actions]"

Cualquiera de los ítems de abajo si está en tu mensaje de commit no surtirá efecto en los actions.

• [skip ci]
• [no ci]
• [ci skip]
• [skip actions]
• [actions skip]