yaml shellcheck

Yaml-Shellcheck

Wrapper Script เพื่อเรียกใช้ Shellcheck บนไฟล์ Yaml CI-Config รูปแบบที่ได้รับการสนับสนุนในปัจจุบันคือ BitBucket Pipelines, Gitlab CI, การกระทำของ GitHub, Drone CI, Circleci และ (จำกัด มาก) Ansible

การใช้งาน

เปลือก

ต้องการ Python 3 พร้อม Library 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

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 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 กับสาย shebang ขวา
• นิพจน์จะถูกแทนที่ด้วยตัวแปรง่าย ๆ ก่อนที่จะใช้ Shellcheck

เสียงพึมพำ CI

Drone CI มีโครงสร้างไฟล์ที่ง่ายมาก เท่าที่ฉันสามารถบอกได้ว่ามีเพียงเงื่อนไข แต่ไม่มีการทำรังลึกหรือรวม รายการคำสั่งทั้งหมดจะถูกต่อกันและตรวจสอบเป็นเชลล์สคริปต์

วงกลม

Circleci มีตัวเลือกมากมาย แต่โชคดีที่การทำรังของ jobs.*.steps.run องค์ประกอบสคริปต์นั้นตรงไปตรงมา รายการคำสั่งทั้งหมดจะถูกต่อกันและตรวจสอบเป็นเชลล์สคริปต์

• รองรับคุณลักษณะ shell
• ค่าไปป์ไลน์และพารามิเตอร์จะถูกละเว้นและแทนที่ด้วยตัวแปรเชลล์ตัวยึดตำแหน่ง

ท่อ Gitlab CI

ไฟล์ Gitlab CI มีโครงสร้างมากขึ้นและเราพยายามสนับสนุนมันมากขึ้น

• script before_script , after_script : gitlab ไม่มีหนึ่ง แต่แอตทริบิวต์เชลล์สคริปต์ที่แตกต่างกันสามตัวซึ่งอ่านเป็นสคริปต์อิสระสามสคริปต์ ใน gitlab before_script และ script จะถูกต่อกันและดำเนินการในกระบวนการเชลล์เดียวในขณะที่ after_script จะเริ่มกระบวนการเชลล์ใหม่เสมอ สิ่งนี้มีความหมายบางอย่างสำหรับการมองเห็นตัวแปร ฯลฯ และถูกละเว้นในเครื่องมือนี้
• ไม่ได้ include การสนับสนุนไม่ได้รับการสนับสนุนไฟล์ YAML ทุกไฟล์จะถูกแยกวิเคราะห์ด้วยตัวเอง สำหรับท่อขนาดใหญ่ที่มีหลายคนรวมถึงคุณอาจต้องการใช้เครื่องมืออื่น ๆ เพื่อแก้ไขทั้งหมดรวมถึงจากนั้นเรียกใช้ YAML_SHELLCHECK ในไฟล์ YAML ที่ผสาน
• !reference เป็นแบบกึ่งสนับสนุนเราอ่านแท็กและแทรกตัวยึดตำแหน่งเท่านั้นเพื่อไม่ให้แยกการแยกวิเคราะห์ Yaml (สิ่งที่ต้องทำควรง่ายต่อการปรับปรุง)
• ตัดสินใจที่จะ ไม่ สนับสนุนการตรวจสอบ variables shellcheck ตรวจสอบตัวแปรกรณีล่างสำหรับการกำหนดก่อนการใช้งาน แต่จะถือว่าชื่อตัวแปรกรณีส่วนบนทั้งหมดมีให้ภายนอก -งาน IMHO Gitlab CI ควรปฏิบัติตามการประชุมและใช้ชื่อตัวแปรกรณีส่วนบนสำหรับตัวแปร CI/CD

ตอบได้

การสนับสนุน ANSIBLE มี จำกัด เครื่องมือนี้อ่าน playbook ansible หรือไฟล์งานที่มีรายการ YAML

จนถึงตอนนี้มันรับรู้องค์ประกอบรายการสามประเภท:

• งานที่ใช้โมดูล shell (หรือ ansible.builtin.shell )
• องค์ประกอบ playbook ที่มีแอตทริบิวต์ tasks
• บล็อก ( block ) สำหรับรายการงานซ้อน
• การแสดงออกของ Jinja ( {{ ... }} ) จะถูกละเว้นและแทนที่ด้วยตัวแปรเชลล์ตัวยึดตำแหน่ง

ทั่วไป

ไฟล์ถูกอ่านด้วยตัวแยกวิเคราะห์ Yaml ดังนั้นจุดยึด Yaml ทั้งหมดได้รับการแก้ไข ไม่มีการตรวจสอบเพิ่มเติมเกี่ยวกับชนิดข้อมูลหรือโครงสร้าง

หลังจากการใช้ BitBucket/Gitlab บล็อกสคริปต์อาจมีสตริงหรืออาร์เรย์ของสตริง