GitHub Super-Linter

El pasado día 18, GitHub anunciaba, parafraseando al Señor de los Anillos "un linter para gobernarlos a todos", el nuevo GitHub Super-Linter. Este linter es una especie de orquestador que ejecuta una combinación de varios linters, está escrito en bash y realiza una validación del código fuente del repositorio cuando se produce la ejecución de la GitHub Action, pudiendo validar diferentes lenguajes en la misma operación.

Sus principales características:

• Previene de consolidar código inconsistente en la rama master.
• Ayuda a introducir best practices en el código en diferentes lenguajes.
• Establece las líneas maestras en el diseño y el formato.
• Automatiza y simplifica el proceso de revisión del código.

Con estas características y objetivos, lo que se persigue fundamentalmente es lograr producir un código más consistente, limpio y estable.

Aunque está previsto que a futuro valide más lenguajes, estos son los que están actualmente soportados:

• Ansible
• CSS
• CoffeeScript
• Dockerfile
• Golang
• JavaScript
• JSON
• Markdown
• Perl
• Python3
• Ruby
• Shell
• Terraform
• TypeScript
• XML
• YAML
• ENV

Funcionamiento

En una nueva o en una GitHub Action existente, modificamos el yaml para incluir una llamada al Super-Linter.

Para ello, en modo edición del workflow, localizamos en el Marketplace esta GitHub Action.

Por ejemplo, a la hora de realizar un Pull Request sobre la rama master, podemos definir:

1. Checkout
2. Hacer la magia de Super-Linter

name: Validate code

on:
  pull_request:
    branches: master

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Super-Linter
      uses: github/super-linter@v2.1.0    

Una vez se ejecuta la action, podemos ver cómo procesa todos los ficheros de código de nuestra solución.

Dependiendo de los lenguajes empleados en nuestra solución, se puede determinar si habilitar o deshabilitar comprobaciones, mediante la modificación de la configuración de las variables de entorno de Super-Linter.

Si el código no supera las comprobaciones, el workflow fallará, si hay configurados otros pasos, no continuará realizándolos y marcará como failed ese Pull Request.

Conclusiones

Esta solución debe ser un must en nuestros proyectos, es fundamental para establecer unas reglas comunes de codificación dentro de un equipo de trabajo, simplifica la homogenización del código y también el esfuerzo a la hora de validar un Pull Request, es una buena noticia que, herramientas como esta, vengan con tanta funcionalidad útil de caja y estén disponible de forma abierta.