los parámetros de los actions se pasan con el parámetro “with:”
Conoce Github Actions
Automatización de DevOps con GitHub Actions
GitHub Actions: Automatización de CICD para Desarrolladores
Componentes y Conceptos Clave de GitHub Actions
Quiz: Conoce Github Actions
Creación de Workflow Files
Automatización de Tareas con GitHub Actions
Automatización con GitHub Actions para Desarrolladores
Triggers en GitHub Actions: Automatización y Ejemplos Prácticos
Eventos y Triggers en GitHub Actions
Uso de Contextos en GitHub Actions
Uso de Variables de Entorno en GitHub Actions
Variables y Secretos en GitHub Actions
Quiz: Creación de Workflow Files
Como encontrar bugs en un workflow
Configuración de Secrets en GitHub Actions
Quiz: Como encontrar bugs en un workflow
Casos de Uso de GitHub Actions
Flujos de Integración Continua con GitHub Actions
Compilación de Imágenes Docker en AWS, GCP y Azure
Flujo de Despliegue Continuo con Docker en AWS, GCP y Azure
Automatización de Tareas con GitHub Actions
Buenas Prácticas para Optimizar GitHub Actions
Costos y facturación en GitHub Actions
Costos y Tarifas de GitHub Actions: Minutos y Almacenamiento
Quiz: Costos y facturación en GitHub Actions
Cierre
Automatización de Tareas con GitHub Actions
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Flujos de Integración Continua con GitHub Actions
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 6
Preguntas 1
Ordenar por:
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?