Conceptos básicos del flujo de trabajo con GitHub Actions

**- Eventos:** * Un evento es una acción específica que puede llamar o lanzar el flujo de CI CD en GitHub Actions o activar un Workflow. * Puede originarse desde Github o de forma externa mediante una api rest. * Algunos eventos desde GitHub pueden ser, pull requests, push a una rama específica, creación de un GitHub Issue, etc. * Eventos mediante api rest pueden ser, un botón en la aplicación que llame a una api que lanze un proceso que cree una nueva versión de la aplicación o alguna llamada a api cualquiera. * En los archivos de configuración, se declara como "on", seguido del nombre del evento en una lista. Ejemplo: on: \[pull\_request] **- Runners:** * Es un servidor o una máquina que va a correr la serie de pasos de nuestro flujo de CI CD. * Un runner puede ejecutar solo un Job a la vez. * GitHub provee runners de Ubuntu, Windows y MacOS. * En caso de tenerlo, puede configurar y usarse un servidor propio para correrlo como runner en GitHub Actions. * En los archivos de configuración, se declara como "runs-on", seguido del nombre de la máquina, por recomendación suele ser "ubuntu-latest". * Ejemplo: runs-on: ubuntu-latest **- Flujo de ejecución:** * Workflow -> Job -> Step -> Action. * Un Workflow puede tener uno o más jobs. * Un Job puede tener uno o más steps. * Un Step puede contener un action o ejecutar un script. **- Workflows:** * Es un proceso automatizado configurable que ejecutará en GitHub uno o mas Jobs. * Se define mediante un archivo .YAML en el directorio .github/workflows del repositorio. * Un repositorio puede tener varios workflows, por ej: workflow de build, de deploy tests unitarios, tests de integración, tests e2e. Cada uno en su propio archivo. **- Jobs:** * Es un conjunto de Steps (pasos o tareas) en un Workflow que se ejecutan en un mismo runner. * Los steps se ejecutarán en orden, en forma secuencial, y uno será dependiente de otro. Por ejemplo, si hay 3 Steps, y falla el segundo, el tercero ya no correrá. * Al ser ejecutados en un mismo Runner, los Steps pueden compartir datos o variables uno a otros. * En los archivos de configuración, se declara como "jobs", seguido de los steps que contendrá. **- Steps:** * Puede ser un script de shell (linea de comandos). * Puede ser un Action que se ejecutará. * En los archivos de configuración, se declara como "steps". * En los archivos de configuración, en caso de ejecutar un script, lo declararemos más hacia abajo con "run" seguido del comando. Ejemplo: run: npm install. * En los archivos de configuración, en caso de ejecutar un action, lo declararemos más hacia abajo con "uses", seguido del action. Ejemplo: uses: actions@action. **- Actions:** * Aplicación personalizada que realiza una tarea compleja repetitiva. * Ayuda a reducir código repetido, puede ser algo tedioso tener que configurarlo desde 0. * Se puede usar Actions propias o Actions publicadas de GitHub. * Algunas de las muchas acciones pueden ser, hacer un checkout de repositorio, instalar node. * Aquí se pueden ver las distintas acciones que existen: <https://github.com/marketplace?type=actions.> **- Archivos .yaml** * Es un superset de archivos .json, quiere decir que un archivo .json puede llegar a pasar a ser .yaml

Interesante, gracias

# Concepto basicos del flujo de trabajo con GitHub Actions GitHub Actions utiliza un sistema basado en flujos de trabajo (*workflows*) para automatizar procesos dentro de un repositorio. Sus principales componentes son: * **Workflow (Flujo de trabajo)**Es el proceso automatizado que define una serie de tareas a ejecutar. Se configura mediante un archivo YAML dentro del repositorio (`.github/workflows/`). Un workflow se activa por eventos como *push*, *pull requests* o ejecuciones programadas (*cron*). * **Event (Evento)**Es lo que activa un *workflow*. Puede ser un evento en el repositorio, como: * **Eventos de Git:** `push`, `pull_request`, `branch_protection_rule`, etc. * **Eventos en GitHub:** `issue`, `release`, `schedule` (cron jobs), etc. * **Eventos manuales:** `workflow_dispatch` permite ejecutar workflows manualmente desde la interfaz de GitHub. * **Runners:** Servidores donde se ejecutan los workflows (hospedados por GitHub o propios). * **Job (Trabajo)**Es un conjunto de pasos (*steps*) que se ejecutan en un mismo entorno. Un workflow puede contener múltiples jobs que pueden ejecutarse en paralelo o en secuencia. * **Step (Paso)**Son las tareas individuales dentro de un *job*. Pueden ejecutar comandos en la terminal o utilizar *actions* predefinidas. ``` name: CI Pipeline on: \[push, pull\_request] jobs: build: runs-on: ubuntu-latest steps: \- name: Checkout del código uses: actions/checkout@v4 \- name: Instalar dependencias run: npm install \- name: Ejecutar pruebas run: npm test ``` * **Action (Acción)**Es una unidad reutilizable dentro de un *step*. Pueden ser personalizadas o provenientes del marketplace de GitHub. Ejemplo: una acción puede instalar dependencias, ejecutar pruebas o desplegar código automáticamente.

- **Workflow**: Proceso automatizado que ejecuta uno o más Jobs, definido en un archivo YAML dentro de la carpeta `.github/workflows`. - **Job**: Conjunto de tareas (Steps) dentro de un Workflow. Se ejecutan en el mismo runner y en orden secuencial. - **Step**: Tarea individual dentro de un Job. Puede ser un script o una Action. - **Action**: Aplicación que realiza tareas complejas de manera repetitiva, disponible en GitHub Marketplace. - **Event**: Acción que activa un Workflow, como un Pull Request o un Push. - **Runner**: Servidor donde se ejecutan los Workflows. Puede ser gestionado por GitHub o personalizado. Estos conceptos forman la base de GitHub Actions para CI/CD.