los parámetros de los actions se pasan con el parámetro “with:”
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,
Integración continua CI: Test
12/18Recursos
A lo largo de este recorrido, descubriremos los componentes, conceptos y sintaxis esenciales que hacen de GitHub Actions una herramienta clave para cualquier flujo de trabajo de desarrollo de software.
¿Cómo Aplicar lo Aprendido a un Proyecto Personal?
Para internalizar y aplicar todo lo aprendido, te recomiendo que elijas un proyecto personal en el que hayas estado trabajando. Esto debe ser un proyecto original, o bien, puede ser un proyecto open source que encuentres interesante y disponga en GitHub de forma pública.
¿Cuál es un Ejemplo de Cómo Implementar un Flujo de Integración y Despliegue Continuo?
Un ejemplo específico que vamos a trabajar es el proyecto UIS Shop, mantenido por OWASP, una organización internacional que se centra en la seguridad de Internet. Este proyecto es un e-commerce, realizado con Angular para el frontend y Node para el backend, que vende zumos y algunos productos relacionados.
Este proyecto también cuenta con su propia serie de tests unitarios, integración, fin a fin y otros automatizables. Además, la aplicación se puede compilar en un formato (Docker), cumpliendo con los requisitos del flujo de integración continua. El resultado de esta compilación puede llevarse a cualquier tipo de servidor para su despliegue continuo.
Posteriormente, mostraremos cómo crear flows específicos para cada tipo de test y trabajaremos en distintos jobs dentro de estos flujos. Además, aprenderemos la herramienta "Retry", cómo copiar y subir reportes de coverage, y cómo verificar nuestra aplicación en distintos contextos y navegadores.
GitHub Actions ofrece la flexibilidad y el nivel de personalización que necesitas para maquetar eficientemente tus proyectos. ¡Vamos a descubrirlo juntos!
Aportes 7
Preguntas 1
Ordenar por:
Aquí hay más documentación sobre por qué utilizar hashes completos en los actions que usamos, y no tags Documentación
Es importante conocer el alcance de cada tipo de test, dejo un poco de información de ellos.
Test unitario -> Evaluación a nivel de componente para asegurar que cada unidad de código funcione correctamente de manera aislada.
Test de integración -> Verificación de la interacción y correcta combinación de unidades de código para asegurar el funcionamiento adecuado del sistema completo.
Test de Humo -> Prueba inicial para identificar fallos básicos y verificar que las funciones principales del sistema estén operativas.
needs indica que un job solo se puede ejecutar cuando los jobs especificados hayan concluido correctamente
```js
needs: [test,test-api]
```
Sobre el uso de pipe (|) y signo mayor qué (>), ambos se usan para representar comandos/textos multilinea. La diferencia es que el '|' toma literal el texto presentado a continuación, salto de líneas incluido.
```js
run: |
npm install --ignore-scripts
cd frontend
```Sería
```js
npm install --ignore-scripts <ENTER>
cd frontend
```
Mientras que el '>', toma todas las siguientes líneas y las concatena, siendo interpretadas como una línea única, sin caracter de salto de línea
```js
name: "Lint customization configs"
run: >
npm run lint:config -- -f ./config/7ms.yml &&
npm run lint:config -- -f ./config/addo.yml &&
```Pasa a ser:
`npm run lint:config -- -f ./config/7ms.yml && npm run lint:config -- -f ./config/addo.yml`
En esencia, al usar una etiqueta de versión (como `v3`) en nuestros actions, existe el riesgo, aunque pequeño, de que dicha etiqueta sea reasignada a un commit diferente debido a malas prácticas. Esto puede llevar a cambios inesperados en el código al que apunta la etiqueta. Por otro lado, al referenciar directamente un commit, garantizamos la inmutabilidad del código, ya que los commits son fijos y no pueden cambiar.
Tengo una duda respecto a los actions/checkout; Para un job que se encuentre selfHosted, el actions/checkout descarga el repositorio dentro de la carpeta del runner dentro del servidor, cierto?
Si yo dentro del servidor cuento ya con una carpeta donde tengo los repositorios,y especifico el directorio de trabajo (working-directory) puedo omitir esta parte de checkout repositorio y configuración de Node en mis actions de despliegue ? Hay alguna buena practica que lo impida?
De antemano muchas gracias.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?