name: hola-mundo #Nombre del workflow
on: [push] #evento que lo activará
jobs: #Definición de los jobs
hola-mundo: #Nombre del job
runs-on: ubuntu-latest #Maquina en la que correrá
steps: #Lista de steps del job hola-mundo
- name: Public IP #Nombre del step
id : ip #identificador usable dentro del job para otros steps
uses: haythem/[email protected] #Usará el action haythem/public-ip
- name: Hola mundo #Segundo step de nombre Hola mundo
run : echo ¡Hola Mundo desde ${{ steps.ip.outputs.ipv4 }}! #bash
Conoce Github Actions
Qué aprenderás de GitHub Actions
Qué son GitHub Actions y qué es CI/CD
Conceptos básicos del flujo de trabajo con GitHub Actions
Quiz: Conoce Github Actions
Creación de Workflow Files
Creando tu primer workflow file con GitHub Actions
Cómo es la sintaxis de workflow files
Triggers: eventos que inician workflows en GitHub Actions
Expresiones para agregar lógica a un workflow
Uso de contexto para acceder a información sobre un workflow
Uso de variables para almacenar información para reutilizar en un workflow
Secrets: almacena información confidencial para reutilizar en un workflow
Quiz: Creación de Workflow Files
Como encontrar bugs en un workflow
Revisando logs para debuggear errores con GitHub Actions
Quiz: Como encontrar bugs en un workflow
Casos de Uso de GitHub Actions
Integración continua CI: Test
Integración continua CI: Compilación
Despliegue continuo CD: Desplegar apps
Automatización de procesos con GitHub Actions
Buenas prácticas al usar GitHub Actions
Costos y facturación en GitHub Actions
Costos y facturación en GitHub Actions
Quiz: Costos y facturación en GitHub Actions
Cierre
Recapitulación del curso: qué aprendiste de GitHub Actions
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Conceptos básicos del flujo de trabajo con GitHub Actions
3/18Recursos
Exploremos a detalle cada componente de GitHub Actions y cómo estos interactúan entre sí para poder automatizar tareas específicas.
¿Cuáles son los componentes principales de GitHub Actions?
Primero, hablemos de los cuatro elementos principales de GitHub Actions: Workflow, Job, Step y Action. Cada uno encapsula al siguiente de manera jerárquica.
Por ejemplo, un Workflow puede contener uno o más Jobs, un Job puede integrar varios Steps, y un Step puede incluir un Action.
¿Qué es un Workflow?
Un Workflow es el proceso más amplio y automatizado que ejecuta uno o varios Jobs. Se define mediante un archivo YAML en la carpeta .github/workflows de cada repositorio y cada repositorio puede tener varios Workflows.
¿Qué es un Job?
Un Job es un conjunto de Steps o tareas que viven dentro de un Workflow. Los Steps de un Job siempre se ejecutan en orden y de forma secuencial, dependiendo del término del anterior.
¿Qué es un Step?
Un Step es una parte del Job que puede ser un script de Shell (un comando en la terminal) o un Action predefinido que se ejecuta.
¿Qué es un Action?
Un Action es una aplicación personalizada que realiza una tarea compleja de forma repetitiva para evitar escribir código repetitivo.
¿Qué otros conceptos son importantes en GitHub Actions?
Aparte de estos cuatro componentes clave, dos conceptos adicionales son esenciales para entender GitHub Actions: Eventos y Runners.
¿Qué es un Evento?
Un Evento es una actividad específica en el repositorio que activa la ejecución de un Workflow. Estos pueden ser internos o externos.
¿Qué es un Runner?
Un Runner es el servidor donde se ejecutan nuestros workflows. GitHub proporciona runners que tienen diferentes sistemas operativos: Ubuntu, Windows o MacOS.
¿Cómo se estructura un Workflow en código?
El formato YAML se utiliza para definir un Workflow, y se suele alojar en la carpeta .github de tu repositorio. Un archivo de workflow está organizado jerárquicamente, con etiquetas para identificar diferentes secciones, como Jobs y Steps.
¿Cómo se integran los Actions en un Workflow?
Los Actions permiten condensar múltiples tareas en una sola tarea. Estos pueden ser desarrollados por nosotros mismos, comunidades, GitHub o empresas, y están disponibles en el GitHub Marketplace.
Al final, entender y usar GitHub Actions es la clave para implementar la integración continua y el despliegue continuo - permitiendo una mejor automatización y ahorro de tiempo para los desarrolladores.
En la próxima clase, tendrás la oportunidad de crear tu primerión propia GitHub Action, ¡espero verte allí!
Aportes 3
Preguntas 2
Ordenar por:
Los Actions me recuerdan a las imágenes de Docker, en el sentido de que estos vienen listos con las instrucciones que deben de ejecutar
**- 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
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?