yaml shellcheck

yaml-shellcheck

YAML CI-CONFIGファイルでShellCheckを実行するラッパースクリプト。現在サポートされている形式は、Bitbucketパイプライン、Gitlab CI、Github Actions、Drone CI、Circleci、および（非常に限られた）Ansibleです。

使用法

シェル

ライブラリRuamel.yamlとShellCheckを備えたPython 3が必要です。

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

ステータス/戻り値を終了します

ツールは、Man Pageからshellcheckから出口コードで終了します。

 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 

ファイル形式

このツールの主な機能は、YAMLデータ内のどの要素にシェルスクリプトが含まれているかをエンコードすることです。これまでに3つの形式がサポートされています。

Bitbucketパイプライン

BitBucketファイルの処理は非常に簡単です。 pipelinesオブジェクトを備えたファイルは、ビットバケットパイプラインファイルとして読み取られ、内部のすべてのscript属性はシェルスクリプトと見なされます。

GithubアクションとForgejoアクション

GitHubには、アクション（再利用可能なコンポーネント）とワークフロー（スクリプトやアクションを実行できる実際のCI構成）があります。このツールは、同じ機能で両方のファイルタイプを処理しようとします。

GitHubワークフローは、Bitbucketに似ています。 onとjobsオブジェクトを備えたファイルは、githubファイルとして読み取り、内部のすべてのrun属性はシェルスクリプトと見なされます。

または、 inputsとrunsオブジェクトを備えたファイルは、GitHubアクションファイルとして読み取られます。

Forgejoのアクション（https://codeberg.org/が使用しているように）がgithubアクション/ワークフローと同じ構造を意図的に使用することを知ることができる限り、これらについてもここで説明します。

• shell属性はサポートされていません
  これはTODOです。右のシバンラインでshとbashスクリプトのみをチェックするのに十分なシンプルでなければなりません
• シェルチェックを実行する前に、式が単純な変数に置き換えられます

ドローンCI

ドローンCIには非常にシンプルなファイル構造があります。私が言うことができる限り、それには条件しかないが、深い巣はありません。すべてのコマンドリストは連結され、シェルスクリプトとしてチェックされます。

Circleci

Circleciには多くの選択肢がありますが、幸いなことにそのjobs.*.steps.runスクリプト要素は簡単です。すべてのコマンドリストは連結され、シェルスクリプトとしてチェックされます。

• shell属性がサポートされています
• パイプライン値とパラメーターは無視され、プレースホルダーシェル変数に置き換えられます

Gitlab CIパイプライン

Gitlab CIファイルにはより多くの構造があり、それをより多くサポートしようとしています。

• script 、 before_script 、 after_script ：gitlabには1つではなく、3つの独立したスクリプトとして読み取られる3つの異なるシェルスクリプト属性があります。 gitlab before_scriptとscriptでは、単一のシェルプロセスで連結および実行されますが、 after_script常に新しいシェルプロセスを開始します。これは、可視性などにいくつかの意味を持ち、このツールでは無視されています。
• includeはサポートされていません。すべてのYAMLファイルは単独で解析されます。多くの含まれる大規模なパイプラインの場合、他のツールを使用してすべてを解決することをお勧めします。
• !reference半サポートされています。タグを読み取り、ヤムルの解析を破らないようにプレースホルダーを挿入します（TODO、簡単に改善する必要があります）。
• variablesチェックをサポートしないことにしました。 shellcheck 、使用前に割り当ての下位ケース変数をチェックしますが、すべての上部ケース変数名が外部から提供されると想定しています。 -IMHO GitLab CIジョブは、その慣習に従い、CI/CD変数に上限変数名を使用する必要があります。

Ansible

Ansibleサポートは限られています。このツールは、YAMLリストを使用したAnsible Playbookまたはタスクファイルを読み取ります。

これまでのところ、3種類のリスト要素を認識しています。

• shell （またはansible.builtin.shell ）モジュールを使用したタスク。
• tasks属性を含むプレイブック要素。
• ネストされたタスクリストのブロック（ block ）。
• ジンジャ式（ {{ ... }} ）は無視され、プレースホルダーシェル変数に置き換えられます。

一般

ファイルはYAMLパーサーで読み取られるため、すべてのYAMLアンカーが解決されます。データ型または構造に関する追加のチェックはありません。

BitBucket/GitLabの使用に続いて、スクリプトブロックには文字列または文字列の配列が含まれる場合があります。