yaml shellcheck Скачать - загрузка исходного кода yaml shellcheck

yaml shellcheck

Другие категории

v1.5.0

Скачать

Yaml-Shellcheck

Сценарий обертки для запуска ShellCheck на файлах YAML CI-CONFIG. В настоящее время поддерживаемые форматы - это конвейеры Bitbucket, Gitlab CI, GitHub Actions, Drone CI, Circleci и (очень ограниченный) Ansible

Использование

Оболочка

Нуждается в Python 3 с библиотекой Ruamel.yaml и 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)

Статус выхода/возвращаемые значения

Инструмент выходит с кода выхода из 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).

Докер

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

Гитлаб 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 содержат сценарии оболочки. До настоящего времени поддерживаются три формата.

Bitbucket Pipelines

Обработка файлов Bitbucket очень проста. Файл с объектом pipelines читается как файл трубопровода Bitbucket, и каждый атрибут script внутри считается скриптом оболочки.

Действия GitHub & Forgejo

GitHub имеет действия (многоразовые компоненты) и рабочие процессы (реальная конфигурация CI, которая может запускать сценарии и/или действия). Этот инструмент пытается обрабатывать оба типа файлов в одной и той же функции.

Рабочие процессы GitHub похожи на BitBucket. Файл с on и объектом jobs читается как файл GitHub, и каждый атрибут run внутри считается скриптом оболочки.

В качестве альтернативы файл с inputs и объектом runs читается как файл действий GitHub.

Насколько я могу судить, действия Forgejo (как используются, например, https://codeberg.org/) намеренно используют ту же структуру, что и действия/рабочие процессы Github, так что они также рассмотрены здесь.

Атрибуты shell не поддерживаются
Это тодо, он должен быть достаточно простым, чтобы проверить sh и bash Scripts с правой линией Шебанг
Выражения заменяются простой переменной перед запуском ShellCheck

Беспилотник CI

Drone CI имеет очень простую структуру файла. Насколько я могу судить, есть только условия, но нет глубокого гнездования или включения. Все списки команд объединяются и проверяются как сценарий оболочки.

Circleci

У Circleci есть много вариантов, но, к счастью, гнездование его jobs.*.steps.run Все списки команд объединяются и проверяются как сценарий оболочки.

Атрибуты shell поддерживаются
Значения и параметры трубопроводов игнорируются и заменяются переменными заполнителя.

Гитлаб CI Трубопроводы

Файлы Gitlab CI имеют больше структуры, и мы стараемся поддержать его больше.

script , before_script , after_script : Gitlab имеет не один, а три различных атрибута скрипта оболочки, которые читаются как три независимых сценария. В gitlab before_script и script объединяются и выполняются в одном процессе оболочки, тогда как after_script всегда начинает новый процесс оболочки. Это имеет некоторые последствия для видимости переменной и т. Д. И игнорируется в этом инструменте.
include не поддерживается, каждый файл YAML проанализирован сам по себе. Для больших трубопроводов со многими включают, что вы, возможно, захотите использовать другие инструменты для разрешения всех включающих, а затем запустить yaml_shellcheck в объединенном файле YAML.
!reference полученная, мы читаем только тег и вставляем заполнителя, чтобы не сломать анализ YAML (Todo, должен быть прост в улучшении).
решил не поддерживать проверку variables . shellcheck проверяет переменные с более низким содержанием на назначения перед использованием, но предполагает, что все имена переменных верхнего часа предоставляются внешне. -Имхо Gitlab CI Задание должно следовать этой конвенции и использовать имена переменных переменных верхнего часа для переменных CI/CD.

Ansible

Ансибильная поддержка ограничена. Этот инструмент считывает Ansible Playbook или файлы задач с списками YAML.

Пока что он распознает три вида элементов списка:

Задачи с использованием модуля shell (или ansible.builtin.shell ).
Элементы Playbook, содержащие атрибут tasks .
Блоки ( block ) для вложенных списков задач.
Экспрессии Jinja ( {{ ... }} ) игнорируются и заменяются переменными заполнителя.