yaml shellcheck

Yaml-Shellcheck

Wrapper-Skript zum Ausführen von Shellcheck auf YAML CI-Config-Dateien. Derzeit unterstützte Formate sind Bitbucket -Pipelines, Gitlab CI, Github -Aktionen, Drohnen -CI, Circleci und (sehr begrenzt) Ansible

Verwendung

Hülse

Benötigt Python 3 mit Bibliothek Ruamel.yaml und 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)

Status/Rückgabewerte beenden

Das Tool beendet mit dem Ausgangscode von shellcheck aus ihrer Mannseite:

 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 

Dateiformate

Die Hauptfunktion dieses Tools besteht darin, welche Elemente innerhalb der YAML -Daten Shell -Skripte enthalten zu können. Bisher werden drei Formate unterstützt.

Bitbucket -Pipelines

Die Behandlung von Bitbucket -Dateien ist sehr einfach. Eine Datei mit einem pipelines -Objekt wird als Bitbucket -Pipeline -Datei gelesen, und jedes script innerhalb wird als Shell -Skript angesehen.

Github -Aktionen & Forgejo -Aktionen

GitHub verfügt über Aktionen (wiederverwendbare Komponenten) und Workflows (die reale CI -Konfiguration, die Skripte und/oder Aktionen ausführen kann). Dieses Tool versucht beide Dateitypen in derselben Funktion zu verarbeiten.

Github -Workflows ähneln Bitbucket. Eine Datei mit einem on und einem jobs -Objekt wird als Github -Datei gelesen, und jedes run -Attribut in Inneren wird als Shell -Skript angesehen.

Alternativ wird eine Datei mit inputs und ein runs Objekt als GitHub -Aktionsdatei gelesen.

Soweit ich Forgejo -Aktionen (wie verwendet von https://codeeberg.org/) erkennen kann, verwenden Sie absichtlich die gleiche Struktur wie GitHub -Aktionen/Workflows, sodass diese auch hier behandelt werden.

• shell -Attribute werden nicht unterstützt
  Dies sh bash Todo
• Ausdrücke werden vor dem Ausführen von Shellcheck durch eine einfache Variable ersetzt

Drohne CI

Die Drohne CI hat eine sehr einfache Dateistruktur. Soweit ich das erkennen kann, hat es nur Bedingungen, aber keine tiefe Verschachtelung oder Einschlüsse. Alle Befehlslisten werden verkettet und als Shell -Skript überprüft.

Circleci

Circleci hat viele Möglichkeiten, aber zum Glück ist die Verschachtelung seiner jobs.*.steps.run Alle Befehlslisten werden verkettet und als Shell -Skript überprüft.

• shell -Attribute werden unterstützt
• Die Pipeline -Werte und -Parameter werden ignoriert und durch Platzhalter -Shell -Variablen ersetzt

Gitlab CI Pipelines

Gitlab CI -Dateien haben mehr Struktur, und wir versuchen, mehr davon zu unterstützen.

• script , before_script , after_script : GitLab hat nicht eine, sondern drei verschiedene Shell -Skriptattribute, die als drei unabhängige Skripte gelesen werden. In GitLab before_script und script werden in einem einzigen Shell -Prozess verkettet und ausgeführt, während after_script immer einen neuen Shell -Prozess startet. Dies hat einige Auswirkungen auf die variable Sichtbarkeit usw. und wird in diesem Tool ignoriert.
• include wird nicht unterstützt, jede YAML -Datei wird von selbst analysiert. Für große Pipelines mit vielen Einschlüssen möchten Sie möglicherweise andere Tools verwenden, um alle inklusive zu beheben und dann YAML_SHELLcheck in der fusionierten YAML -Datei auszuführen.
• !reference ist halb unterstützt. Wir lesen nur das Tag und fügen einen Platzhalter ein, um die Yaml-Parsen nicht zu brechen (Todo sollte einfach zu verbessern sein).
• beschlossen, keine variables zu überprüfen. shellcheck überprüft Variablen mit unterer Case auf Zuordnungen vor der Verwendung, wird jedoch vorausgesetzt, dass alle Variablennamen obere Fälle extern bereitgestellt werden. -IMHO GitLab CI-Jobs sollten dieser Konvention folgen und für CI/CD-Variablen in oberen Fällen Variablennamen verwenden.

Ansible

Ansible -Unterstützung ist begrenzt. Dieses Tool liest Ansible Playbook oder Task -Dateien mit YAML -Listen.

Bisher erkennt es drei Arten von Listenelementen:

• Aufgaben mit dem Modul shell (oder ansible.builtin.shell ).
• Spielbuchelemente, die ein tasks enthalten.
• Blöcke ( block ) für verschachtelte Aufgabenlisten.
• Jinja Expressions ( {{ ... }} ) werden ignoriert und durch Platzhalter -Shell -Variablen ersetzt.

Gemeinsam

Dateien werden mit einem YAML -Parser gelesen, sodass alle YAML -Anker behoben sind. Es gibt keine zusätzliche Überprüfung der Datentypen oder der Struktur.

Nach der Verwendung von Bitbucket/GitLab kann ein Skriptblock eine Zeichenfolge oder ein Array von Zeichenfolgen enthalten.