yaml shellcheck

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 ، من صفحة 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).

عامل ميناء

 # 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 التي تحتوي على نصوص قذيفة. حتى الآن يتم دعم ثلاثة تنسيقات.

خطوط الأنابيب Bitbucket

معالجة ملفات bitbucket بسيطة للغاية. تتم قراءة ملف يحتوي على كائن pipelines كملف خط أنابيب Bitbucket ، ويعتبر كل سمة script داخل برنامج SHELL.

إجراءات جيثب وأفعال فورجيجو

لدى Github إجراءات (مكونات قابلة لإعادة الاستخدام) وسير العمل (تكوين CI الحقيقي الذي قد يقوم بتشغيل البرامج النصية و/أو الإجراءات). تحاول هذه الأداة التعامل مع كلا النوعين من الملفات في نفس الوظيفة.

مهام سير العمل Github تشبه Bitbucket. يتم قراءة ملف يحتوي على سمة on وكائن jobs كملف github ، ويعتبر كل سمة run في الداخل برنامجًا نصيًا shell.

بدلاً من ذلك ، يتم قراءة ملف يحتوي inputs ويتم تشغيل كائن runs كملف إجراءات GitHub.

بقدر ما أستطيع أن أخبر إجراءات Forgejo (كما هو مستخدم على سبيل المثال بواسطة https://codeberg.org/) ، استخدم عن قصد نفس بنية الإجراءات/سير العمل ، لذلك يتم تغطية هذه أيضًا هنا.

• سمات shell غير مدعومة
  هذا عبارة عن تودو ، يجب أن يكون بسيطًا بما bash sh فقط
• يتم استبدال التعبيرات بمتغير بسيط قبل تشغيل shellcheck

الطائرات بدون طيار CI

يحتوي الطائرات بدون طيار CI على بنية ملف بسيطة للغاية. بقدر ما أستطيع أن أقول أنه يحتوي على شروط فقط ، ولكن لا يوجد تعشيش عميق أو يشمل. يتم تسلس جميع قوائم الأوامر والتحقق منها كنصي Shell.

circleci

لدى Circleci العديد من الخيارات ، ولكن لحسن الحظ تعشش jobs.*.steps.run يتم تسلس جميع قوائم الأوامر والتحقق منها كنصي Shell.

• يتم دعم سمات shell
• يتم تجاهل قيم خطوط الأنابيب والمعلمات واستبدالها بمتغيرات قذيفة العناصر النائبة

خطوط الأنابيب Gitlab CI

تحتوي ملفات Gitlab CI على المزيد من بنية ، ونحاول دعم المزيد منها.

• script ، before_script ، after_script : ليس لدى gitlab واحدًا ، ولكن ثلاث سمات نصية مختلفة يتم قراءة ثلاث نصوص مستقلة. في gitlab before_script و script الحصول على متسلسل وتنفيذ في عملية shell واحدة ، في حين أن after_script تبدأ دائما عملية shell جديدة. هذا له بعض الآثار المترتبة على الرؤية المتغيرة وما إلى ذلك ويتم تجاهله في هذه الأداة.
• لا include دعمه ، يتم تحليل كل ملف yaml من تلقاء نفسه. بالنسبة لخطوط الأنابيب الكبيرة التي تحتوي على العديد ، قد ترغب في استخدام أدوات أخرى لحل جميعها ، ثم تشغيل Yaml_ShellCheck على ملف YAML المدمج.
• !reference هو شبه مدعوم ، نقرأ فقط العلامة وإدراج عنصر نائب حتى لا يكسر التحليل YAML (TODO ، يجب أن يكون الأمر بسيطًا).
• قررت عدم دعم التحقق variables . يتحقق shellcheck من متغيرات الحالة المنخفضة للواجبات قبل الاستخدام ، لكنه يفترض أن جميع أسماء المتغيرات العلوية يتم توفيرها خارجيًا. -يجب أن تتبع وظائف IMHO Gitlab CI هذه الاتفاقية واستخدام أسماء متغير الحالات العليا لمتغيرات CI/CD.

Ansible

الدعم Ansible محدود. تقرأ هذه الأداة ملفات playbook أو مهمة ANSIBLE مع قوائم YAML.

حتى الآن يتعرف على ثلاثة أنواع من عناصر القائمة:

• المهام باستخدام وحدة shell (أو ansible.builtin.shell ).
• عناصر Playbook ، التي تحتوي على سمة tasks .
• كتل ( block ) لقوائم المهام المتداخلة.
• يتم تجاهل تعبيرات Jinja ( {{ ... }} ) واستبدالها بمتغيرات قذيفة العنصر النائب.

شائع

تتم قراءة الملفات باستخدام محلل Yaml ، لذلك يتم حل جميع مراسي YAML. لا يوجد فحص إضافي لأنواع البيانات أو الهيكل.

بعد استخدام Bitbucket/Gitlab ، قد تحتوي كتلة البرنامج النصي على سلسلة أو مجموعة من الأوتار.