yaml shellcheck

Yaml-Shellcheck

WRAPPER Script para ejecutar Shellcheck en archivos YAML CI-Config. Los formatos compatibles actualmente son Bitbucket Pipelines, Gitlab CI, GitHub Actions, Drone CI, Circleci y (muy limitado) Ansible

Uso

Caparazón

Necesita Python 3 con la biblioteca ruamel.yaml y shellcheck.

 $ ./yaml_shellcheck.py -h
usage: yaml_shellcheck.py [-h] [-o OUTDIR] [-k] [-d] [-s SHELL] [-c COMMAND] files [files ...]

run shellcheck on script blocks from .gitlab-ci.yml or bitbucket-pipelines.yml

positional arguments:
  files                 YAML files to read

optional arguments:
  -h, --help            show this help message and exit
  -o OUTDIR, --outdir OUTDIR
                        output directory (default: create temporary directory)
  -k, --keep            keep (do not delete) output directory
  -d, --debug           debug output
  -s SHELL, --shell SHELL
                        default shebang line to add to shell script snippets (default: '#!/bin/sh -e')
  -c COMMAND, --command COMMAND
                        shellcheck command to run (default: shellcheck)

Valores de estado/retorno de salida

La herramienta sale con el código de salida de shellcheck , de su página de Hombre:

 ShellCheck uses the follow exit codes:
• 0: All files successfully scanned with no issues.
• 1: All files successfully scanned with some issues.
• 2: Some files could not be processed (e.g. file not found).
• 3: ShellCheck was invoked with bad syntax (e.g. unknown flag).
• 4: ShellCheck was invoked with bad options (e.g. unknown formatter).

Estibador

 # build image
$ docker build . -t yaml_shellcheck:latest
# run image
$ docker run -v ` pwd ` :/app yaml_shellcheck app/ * .yaml

Gitlab CI

 lint_yaml_shellcheck :
  image :
    name : quay.io/mschuette/yaml-shellcheck:latest
    entrypoint : [""]
  script :
    - find . -name *.yaml -or -name *.yml | xargs python3 yaml_shellcheck.py 

Formatos de archivo

La función principal de esta herramienta es codificar qué elementos dentro de los datos YAML contienen scripts de shell. Hasta ahora se apoyan tres formatos.

Tuberías de bitbucket

Manejo de archivos bitbucket es muy simple. Un archivo con un objeto pipelines se lee como un archivo de tubería de Bitbucket, y cada atributo script en el interior se considera un script de shell.

Acciones de Github y acciones Forgejo

GitHub tiene acciones (componentes reutilizables) y flujos de trabajo (la configuración de CI real que puede ejecutar scripts y/o acciones). Esta herramienta intenta manejar ambos tipos de archivos en la misma función.

Los flujos de trabajo de GitHub son similares a Bitbucket. Un archivo con un atributo on y un objeto jobs se lee como un archivo GitHub, y cada atributo run dentro se considera un script de shell.

Alternativamente, un archivo con un objeto inputs y runs se lee como un archivo de acciones de GitHub.

Por lo que puedo decir, las acciones de Forgejo (como lo usan por ejemplo, https://codeberg.org/) usa intencionalmente la misma estructura que las acciones/flujos de trabajo de GitHub, por lo que estos también están cubiertos aquí.

• Los atributos shell no son compatibles
  Este es un TODO, debería ser lo suficientemente simple como para ver solo los guiones de sh y bash con la línea de shebang derecha
• Las expresiones se reemplazan con una variable simple antes de ejecutar shellcheck

CI de drones

Drone CI tiene una estructura de archivos muy simple. Por lo que puedo decir, solo tiene condiciones, pero no anidación o incluye profundos. Todas las listas de comandos se concatenan y se verifican como un script de shell.

Circleci

Circleci tiene muchas opciones, pero afortunadamente la anidación de sus jobs.*.steps.run Los elementos de script para correr son sencillos. Todas las listas de comandos se concatenan y se verifican como un script de shell.

• Se admiten los atributos shell
• Los valores y los parámetros de la tubería se ignoran y se reemplazan con variables de shell de marcador de posición

Tuberías de gitlab ci

Los archivos GITLAB CI tienen más estructura, e intentamos admitir más.

• script , before_script , after_script : gitlab no tiene uno, sino tres atributos de script de shell diferentes que se leen como tres scripts independientes. En gitlab before_script script y script se concatenan y ejecutan en un solo proceso de shell, mientras que after_script siempre comienza un nuevo proceso de shell. Esto tiene algunas implicaciones para la visibilidad variable, etc. y se ignora en esta herramienta.
• include no es compatible, cada archivo YAML se analiza por sí solo. Para tuberías grandes con muchas incluye, es posible que desee utilizar otras herramientas para resolver todas las incluyas y luego ejecutar YAML_SHELLCHECK en el archivo YAML fusionado.
• !reference es semi-soportada, solo leemos la etiqueta e insertamos un marcador de posición para no romper el análisis YAML (TODO, debería ser fácil de mejorar).
• Decidió no admitir la verificación variables . shellcheck verifica las variables de caso inferior para las tareas antes del uso, pero supone que todos los nombres de variables de caso superior se proporcionan externamente. -En mi humilde opinión, los trabajos de GITLAB CI deben seguir esa convención y usar nombres de variables de caso superior para variables CI/CD.

Ansible

El soporte ansible es limitado. Esta herramienta lee Ansible Playbook o archivos de tareas con listas YAML.

Hasta ahora reconoce tres tipos de elementos de la lista:

• Tareas que usan el módulo shell (o ansible.builtin.shell ).
• Elementos del libro de jugadas, que contienen un atributo tasks .
• Bloques ( block ) para listas de tareas anidadas.
• Expresiones Jinja ( {{ ... }} ) se ignoran y se reemplazan con variables de shell de marcador de posición.

Común

Los archivos se leen con un analizador YAML, por lo que se resuelven todos los anclajes YAML. No hay verificación adicional en los tipos o estructura de datos.

Siguiendo el uso de bitbucket/gitlab, un bloque de script puede contener una cadena o una matriz de cadenas.