yaml shellcheck

yaml-shellcheck

Script wrapper pour exécuter ShellCheck sur les fichiers YAML CI-Config. Les formats actuellement pris en charge sont les pipelines Bitbucket, Gitlab CI, GitHub Actions, Drone CI, Circleci et (très limité)

Usage

Coquille

Besoin de Python 3 avec la bibliothèque Ruamel.yaml et 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)

Valeurs d'état / retour de sortie

L'outil sort avec le code de sortie de shellcheck , de leur page Man:

 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).

Docker

 # 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 

Formats de fichiers

La fonction principale de cet outil est d'encoder les éléments à l'intérieur des données YAML contiennent des scripts shell. Jusqu'à présent, trois formats sont pris en charge.

Pipelines bitbucket

La gestion des fichiers Bitbucket est très simple. Un fichier avec un objet pipelines est lus comme un fichier de pipeline Bitbucket, et chaque attribut script à l'intérieur est considéré comme un script shell.

Actions GitHub et actions de Forgejo

GitHub a des actions (composants réutilisables) et des flux de travail (la configuration CI réelle qui peut exécuter des scripts et / ou des actions). Cet outil essaie de gérer les deux types de fichiers dans la même fonction.

Les flux de travail GitHub sont similaires à BitBucket. Un fichier avec un attribut on et un objet jobs est lus comme un fichier github, et chaque attribut run à l'intérieur est considéré comme un script shell.

Alternativement, un fichier avec des inputs et un objet runs est lus comme un fichier d'action github.

Pour autant que je sache, les actions de forgejo (comme utilisée par exemple par https://codeberg.org/) utilisent intentionnellement la même structure que les actions / flux de travail GitHub, donc ceux-ci sont également couverts ici.

• Les attributs shell ne sont pas pris en charge
  C'est un TODO, il devrait être assez simple pour vérifier uniquement les scripts sh et bash avec une ligne de shebang droite
• Les expressions sont remplacées par une variable simple avant d'exécuter le chèque d'obus

Drone CI

Drone CI a une structure de fichiers très simple. Pour autant que je sache, il n'a que des conditions, mais pas de nidification profonde ou ne comprend. Toutes les listes de commandes sont concaténées et vérifiées en tant que script shell.

Circleci

Circleci a de nombreuses options, mais heureusement, la nidification de ses jobs.*.steps.run Script Elements est simple. Toutes les listes de commandes sont concaténées et vérifiées en tant que script shell.

• Les attributs shell sont pris en charge
• Les valeurs et paramètres du pipeline sont ignorés et remplacés par des variables de coquille d'espace réservé

Pipelines gitlab CI

Les fichiers GitLab CI ont plus de structure et nous essayons d'en soutenir davantage.

• script , before_script , after_script : gitlab n'a pas un, mais trois attributs de script shell différents qui sont lus comme trois scripts indépendants. Dans GitLab before_script et script être concaténés et exécutés dans un seul processus de shell, tandis que after_script démarre toujours un nouveau processus de shell. Cela a quelques implications pour la visibilité variable, etc. et est ignorée dans cet outil.
• include n'est pas pris en charge, chaque fichier YAML est analysé seul. Pour les grands pipelines avec beaucoup, vous pouvez utiliser d'autres outils pour résoudre tous, puis exécuter YAML_SHELLCHECK sur le fichier YAML fusionné.
• !reference est semi-supportée, nous lisons uniquement la balise et insérons un espace réservé afin de ne pas casser l'analyse YAML (TODO, devrait être simple à améliorer).
• décidé de ne pas prendre en charge la vérification variables . shellcheck vérifie les variables de cas inférieures pour les affectations avant l'utilisation, mais il suppose que tous les noms de variables de cas supérieur sont fournis en externe. - Les travaux IMHO GitLab CI doivent suivre cette convention et utiliser des noms de variables de cas supérieure pour les variables CI / CD.

Anable

Le support anable est limité. Cet outil lit Andible Playbook ou Task Files avec les listes YAML.

Jusqu'à présent, il reconnaît trois types d'éléments de liste:

• Tâches à l'aide du module shell (ou ansible.builtin.shell ).
• Playbook Elements, contenant un attribut tasks .
• Blocs ( block ) pour les listes de tâches imbriquées.
• Les expressions Jinja ( {{ ... }} ) sont ignorées et remplacées par des variables de coquille d'espace réservé.

Commun

Les fichiers sont lus avec un analyseur YAML, donc toutes les ancres YAML sont résolues. Il n'y a pas de vérification supplémentaire sur les types de données ou la structure.

Après l'utilisation de Bitbucket / GitLab, un bloc de script peut contenir une chaîne ou un tableau de chaînes.