Automatizar tareas repetitivas en un repositorio deja de ser opcional cuando manejas proyectos con despliegues frecuentes, issues abiertos por meses y archivos que no siguen el estilo acordado. Con GitHub Actions puedes orquestar despliegues en AWS App Runner, ejecutar análisis estático con SonarCloud y corregir formato con un linter, todo sin intervención manual.

Esta guía recorre cuatro workflows prácticos que cualquier mantenedor puede adaptar: ver una aplicación desplegada en la nube, cerrar issues sin actividad, escanear vulnerabilidades y aplicar lint automático.

¿Cómo verificar un despliegue continuo en AWS App Runner?

Después de ejecutar el flujo de CD, GitHub Actions guarda los logs del job correspondiente al proveedor elegido. En la pestaña Actions seleccionas el run más reciente, abres el job de AWS y bajas hasta el step que actualiza la app en App Runner [3:10].

Ahí encuentras un campo service URL. Esa URL te lleva directamente a la aplicación corriendo en producción, en este caso una versión de la tienda Juice Shop hospedada en AWS App Runner en lugar de Heroku.

¿Qué es AWS App Runner? Es un servicio gestionado de AWS que despliega aplicaciones web y APIs desde un repositorio o imagen de contenedor sin que tengas que configurar servidores ni balanceadores.

¿Cómo cerrar issues y pull requests sin actividad?

El primer workflow automatiza la limpieza del backlog. Se llama Sin actividad y se ejecuta con un disparador tipo schedule usando sintaxis cron [5:30].

La expresión 30 1 * * * significa que corre todos los días a la 1:30 a.m. en zona horaria UTC. El primer valor es el minuto, el segundo la hora, y los asteriscos cubren cualquier día y mes.

¿Qué hace el action Stale de GitHub?

El job corre en Ubuntu y usa un único step con el action oficial Stale v7. Su comportamiento por defecto:

• Marca como inactivo cualquier issue o pull request sin comentarios ni cambios durante más de 60 días.
• Publica una advertencia configurable, por ejemplo: este issue no tiene actividad desde hace más de 60 días, si no tiene actividad en los próximos siete días, se eliminará.
• Si pasan 7 días más sin respuesta, cierra el elemento y le agrega la etiqueta Sin actividad.

El maintainer puede revisar esa etiqueta y, si el tema sigue siendo importante, retirarla para evitar el cierre. Todos los plazos, nombres de labels y excepciones por etiqueta se configuran como parámetros del action desde su documentación en el marketplace.

¿Cómo hacer análisis estático de seguridad con SonarCloud?

El segundo workflow analiza vulnerabilidades en el código sin compilarlo ni ejecutarlo. Esto es exactamente lo que hace un análisis estático de código: revisar archivos en busca de fallas de seguridad usando solo el contenido fuente [8:45].

El workflow se dispara con un push a la rama main o cuando se abre un pull request con tipos opened, synchronize o reopened.

• opened: cuando se crea un nuevo pull request.
• synchronize: cuando subes un commit nuevo a una rama con pull request abierto.
• reopened: cuando reabres un pull request previamente cerrado.

¿Qué diferencia hay entre SonarCloud y SonarQube? SonarCloud es la versión SaaS gestionada online, gratuita para repositorios públicos. SonarQube es la versión on-premise que instalas en tus propios servidores.

¿Qué métricas entrega SonarCloud?

El job hace checkout del repositorio y luego ejecuta el action SonarCloud GitHub Action de SonarSource, pasándole tokens almacenados como secretos del repositorio. Esos tokens se generan desde la consola de SonarCloud.

En la consola encuentras métricas clave:

• Bugs: errores funcionales detectados.
• Code smells: código que funciona pero está mal estructurado.
• Vulnerabilities: fallas explotables de seguridad.
• Security hotspots: zonas que requieren revisión manual.
• Coverage: porcentaje de líneas cubiertas por al menos una prueba unitaria.

El proyecto base de ejemplo, Juice Shop, fue creado por OWASP y es vulnerable a propósito para que desarrolladores aprendan a identificar y corregir fallas, por eso muestra un número alto de hallazgos. La medición de coverage es gratuita en repositorios públicos, lo que resuelve el bloqueo que dejaba el job de coverage condicional en flujos anteriores.

¿Cómo formatear archivos automáticamente con un linter?

El último workflow se llama Automatizar formateo de archivos con lint y corre cada vez que haces push a cualquier rama [14:20]. Recuerda que un linter verifica que los archivos sigan un patrón y formato acordado, y puede corregirlos automáticamente cuando no cumplen.

El job lint reproduce los pasos iniciales del flujo de integración continua:

1. Hace checkout del repositorio.
2. Configura Node.js como entorno de ejecución.
3. Configura la CLI de Angular.
4. Instala dependencias necesarias.
5. Ejecuta npm run lint:fix, un script definido en package.json.

Ese comando intenta arreglar automáticamente los archivos que rompen las reglas definidas, evitando que tengas que corregir manualmente cada violación de estilo.

¿Cómo subir los cambios corregidos al repositorio?

Después del fix necesitas confirmar los cambios. Para eso usas el action git-auto-commit-action con estos parámetros:

• commit_message: por ejemplo, autoarreglar los issues de linting.
• branch: la rama desde donde se lanzó, usando el contexto ${{ github.ref }}.
• commit_options: incluye --signoff.
• commit_user_name y commit_user_email: identifican al autor, por ejemplo Juice Shop Bot con un correo asociado.

Esto deja un historial claro de quién aplicó las correcciones y mantiene el repositorio siempre con el formato deseado.

¿Qué otras tareas puedes automatizar con GitHub Actions?

Los cuatro ejemplos cubiertos solo arañan la superficie: despliegue a la nube, gestión de issues abandonados, seguridad estática y lint automático. La flexibilidad de GitHub Actions permite encadenar prácticamente cualquier rutina que hoy hagas a mano.

¿Qué workflow vas a crear tú? Compártelo en los comentarios para que tus compañeros lo vean y lo adapten.