GitHub Actions es una plataforma de CI/CD que nos permite construir, probar y implementar, entre otras tareas, en nuestra canalización. Tiene el concepto de flujos de trabajo que construyen y prueban un repositorio de GitHub. También se puede utilizar GitHub Actions para ejecutar otros flujos de trabajo basados en eventos que ocurren dentro de tu repositorio.
Por ejemplo, puedes tener un workflow para construir y probar solicitudes de extracción, otro workflow para implementar tu aplicación cada vez que se crea una versión, y otro workflow que agrega una etiqueta cada vez que alguien abre un nuevo problema.
Un runner es un servidor que ejecuta el workflow, cada runner ejecuta un solo trabajo a la vez. GitHub Actions proporciona la capacidad de ejecutar runners de Ubuntu Linux, Microsoft Windows y macOS. También puedes alojar tu propio runner en un sistema operativo o hardware específico.
A continuación, puedes ver cómo se ve esto. Tenemos nuestro evento que desencadena nuestro workflow > nuestro workflow consta de dos trabajos > dentro de nuestros trabajos tenemos pasos y luego acciones.
Creo que hay muchas opciones cuando se trata de GitHub Actions. Sí, satisfará tus necesidades de CI/CD en cuanto a construir, probar e implementar tu código y los pasos continuos posteriores.
Voy a utilizar un código de ejemplo vinculado en uno de los recursos de esta sección, vamos a usar `GitHub/super-linter` para verificar nuestro código.
Puedes ver que para uno de nuestros pasos tenemos una acción llamada GitHub/super-linter, y esto se refiere a un paso que ya ha sido escrito por la comunidad. Puedes obtener más información al respecto aquí [Super-Linter](https://github.com/github/super-linter)
"Este repositorio es para la Acción de GitHub para ejecutar un Super-Linter. Es una combinación simple de varios linters, escritos en bash, para ayudar a validar tu código fuente".
"NOTA: Si pasas la variable de entorno `GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}` en tu workflow, entonces el Super-Linter de GitHub marcará el estado de cada ejecución del linter en la sección de comprobaciones de una solicitud de extracción. Sin esto, solo verás el estado general de la ejecución completa. **No es necesario establecer el Secreto de GitHub ya que se establece automáticamente por GitHub, solo necesita pasarse a la acción".**
El texto en negrita es importante tener en cuenta en esta etapa. Lo estamos utilizando, pero no es necesario configurar ninguna variable de entorno dentro de nuestro repositorio.
Utilizaremos el repositorio que usamos en nuestra demostración de Jenkins para probarlo. [Jenkins-HelloWorld](https://github.com/MichaelCade/Jenkins-HelloWorld)
Aquí está nuestro repositorio como lo dejamos en las sesiones de Jenkins.
Para aprovecharlo, tenemos que usar la pestaña "Actions" (Acciones) de arriba para elegir del mercado, lo cual cubriré en breve, o podemos crear nuestros propios archivos usando nuestro código de super-linter mencionado anteriormente. Para crear el tuyo propio, debes crear un nuevo archivo en tu repositorio en esta ubicación exacta: `.github/workflows/nombre_del_flujo_de_trabajo`, asegurándote de que "nombre_del_flujo_de_trabajo" sea algo útil para que lo reconozcas. Aquí dentro podemos tener muchos flujos de trabajo diferentes realizando diferentes trabajos y tareas en nuestro repositorio.
Luego podemos pegar nuestro código y confirmarlo en nuestro repositorio. Si luego nos dirigimos a la pestaña "Actions" (Acciones), ahora veremos nuestro workflow de Super-Linter listado a continuación.
Hemos definido en nuestro código que este workflow se ejecutará cuando enviemos cualquier cosa a nuestro repositorio, por lo que al enviar el archivo super-linter.yml a nuestro repositorio, activamos el workflow.
Como se puede ver en el ejemplo anterior, tenemos algunos errores, probablemente debido a mi habilidad de hacker en comparación con mi habilidad de programación.
Como era de esperar, mi habilidad de hacker mostró algunos problemas y puedes verlos aquí en el [workflow](https://github.com/MichaelCade/Jenkins-HelloWorld/runs/5600278515?check_suite_focus=true).
Ahora, si resolvemos el problema con mi código y enviamos los cambios, nuestro workflow se ejecutará nuevamente (puedes ver en la imagen que llevó un tiempo solucionar nuestros "errores"). Probablemente no se recomienda eliminar un archivo, pero es una forma muy rápida de mostrar que se ha resuelto el problema.
Si haces clic en el botón de workflow nuevo resaltado anteriormente, se abrirá la puerta a una gran cantidad de acciones. Una cosa que quizás hayas notado a lo largo de este desafío es que no queremos reinventar la rueda, queremos pararnos sobre los hombros de gigantes y compartir nuestro código, automatización y habilidades de manera amplia para hacer nuestras vidas más fáciles.
Creo que esto cubre los aspectos fundamentales de GitHub Actions, pero si eres como yo, probablemente estés pensando en cómo más se puede usar GitHub Actions para automatizar muchas tareas.
