---

🎮 Flujo de trabajo manual

Hasta ahora los workflows de GitHub Actions suelen ejecutarse automáticamente cuando ocurre un evento determinado, como un push o la creación de una pull request.

Sin embargo, existen situaciones donde resulta útil lanzar una automatización únicamente cuando un usuario lo decide.

Para ello GitHub proporciona el evento workflow_dispatch.

🚀 Qué es workflow_dispatch

workflow_dispatch permite ejecutar un workflow manualmente desde la interfaz de GitHub.

En lugar de esperar a que ocurra un evento automático, cualquier usuario con permisos adecuados puede iniciar la ejecución cuando lo necesite.

Esto resulta especialmente útil para:

• Despliegues bajo demanda
• Tareas de mantenimiento
• Procesos de validación manual
• Ejecuciones de pruebas específicas
• Automatizaciones administrativas

⚙️ Configuración básica

Para habilitar la ejecución manual únicamente es necesario añadir el evento:

on:  workflow_dispatch:

Una vez definido, GitHub mostrará un botón Run workflow dentro de la pestaña Actions del repositorio.

Desde allí será posible lanzar el workflow cuando sea necesario.

📝 Definiendo parámetros de entrada

Una de las ventajas más interesantes de workflow_dispatch es que permite solicitar información al usuario antes de iniciar la ejecución.

Estos datos se definen mediante inputs.

Por ejemplo:

on:  workflow_dispatch:    inputs:      logging_level:        description: Nivel de logging        required: true      environment:        description: Entorno de despliegue        required: true      dry_run:        description: Ejecutar en modo simulación        required: true      reason:        description: Motivo de la ejecución        required: true

Cuando se ejecute el workflow, GitHub mostrará un formulario para completar estos valores.

🔍 Accediendo a los inputs

Los parámetros proporcionados por el usuario pueden utilizarse dentro del workflow mediante el contexto inputs.

Por ejemplo:

${{ inputs.logging_level }}${{ inputs.environment }}${{ inputs.dry_run }}${{ inputs.reason }}

Esto permite adaptar el comportamiento del workflow según los valores introducidos en cada ejecución.

🧪 Mostrando los valores recibidos

Una forma sencilla de comprobar que los parámetros están llegando correctamente es mostrarlos durante la ejecución:

steps:  - name: Mostrar todos los inputs    env:      LOG_LEVEL: ${{ inputs.logging_level }}      ENVIRONMENT: ${{ inputs.environment }}      DRY_RUN: ${{ inputs.dry_run }}      REASON: ${{ inputs.reason }}    run: |      echo "LOG_LEVEL: $LOG_LEVEL"      echo "ENVIRONMENT: $ENVIRONMENT"      echo "DRY_RUN: $DRY_RUN"      echo "REASON: $REASON"

De esta manera es posible verificar rápidamente qué información recibió el workflow.

🎯 Casos de uso habituales

Los workflows manuales suelen utilizarse para tareas como:

🚢 Despliegues controlados

Permiten seleccionar el entorno de destino antes de iniciar una publicación.

🧹 Mantenimiento

Facilitan la ejecución de tareas administrativas cuando sea necesario.

🧪 Pruebas específicas

Posibilitan lanzar pruebas concretas sin necesidad de realizar commits adicionales.

🔄 Operaciones puntuales

Resultan ideales para acciones que no deben ejecutarse automáticamente.

📌 Ideas clave de esta clase

Quédate con estos conceptos:

• workflow_dispatch permite ejecutar workflows manualmente.
• Los workflows pueden iniciarse desde la interfaz de GitHub.
• Es posible solicitar información al usuario mediante inputs.
• Los parámetros recibidos se acceden usando inputs.
• Los valores pueden utilizarse para personalizar la ejecución.
• Los workflows manuales son ideales para despliegues y tareas bajo demanda.

🚀 Lo siguiente

Ahora que ya sabes cómo lanzar workflows manualmente y recibir parámetros de entrada, el siguiente paso es aprovechar esos datos para crear automatizaciones más flexibles y adaptables a distintos escenarios.

Los inputs permiten convertir un workflow estático en una herramienta reutilizable capaz de comportarse de forma diferente según las necesidades de cada ejecución.

---

💡 Tip: Utiliza workflow_dispatch siempre que una automatización requiera supervisión humana o decisiones previas antes de ejecutarse. Esto aporta flexibilidad sin perder las ventajas de GitHub Actions.