yaml shellcheck

Yaml-Shellcheck

Script Wrapper para executar o ShellCheck nos arquivos YAML CI-Config. Atualmente, os formatos suportados são oleodutos Bitbucket, Gitlab CI, ações do GitHub, Drone CI, Circleci e (muito limitado) Ansible

Uso

Concha

Precisa de Python 3 com a biblioteca ruamel.yaml e 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)

Valores de status de saída/retorno

A ferramenta sai com o código de saída do shellcheck , da página do homem:

 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 

Formatos de arquivo

A principal função desta ferramenta é codificar quais elementos dentro dos dados YAML contêm scripts de shell. Até agora, três formatos são suportados.

Pipelines Bitbucket

O manuseio de arquivos Bitbucket é muito simples. Um arquivo com um objeto pipelines é lido como um arquivo de pipeline Bitbucket, e todo atributo script interno é considerado um script de shell.

Ações do Github e ações forgejo

O GitHub possui ações (componentes reutilizáveis) e fluxos de trabalho (a configuração de IC real que pode executar scripts e/ou ações). Essa ferramenta tenta lidar com os dois tipos de arquivo na mesma função.

Os fluxos de trabalho do GitHub são semelhantes ao Bitbucket. Um arquivo com um atributo on atributo e um objeto jobs é lido como um arquivo github, e cada atributo run interno é considerado um script de shell.

Como alternativa, um arquivo com inputs e um objeto runs é lido como um arquivo de ações do GitHub.

Tanto quanto posso dizer, as ações forgejo (como usado por https://codeberg.org/) usam intencionalmente a mesma estrutura que as ações/fluxos de trabalho do GitHub, portanto, eles também são abordados aqui.

• Os atributos shell não são suportados
  Este é um TODO, deve ser simples o suficiente para verificar apenas scripts sh e bash com linha de shebang correta
• Expressões são substituídas por uma variável simples antes de executar shellcheck

Drone CI

O Drone CI possui uma estrutura de arquivo muito simples. Tanto quanto posso dizer, apenas possui condições, mas não há nidificação profunda ou inclui. Todas as listas de comando são concatenadas e verificadas como um script de shell.

Circleci

A Circleci tem muitas opções, mas felizmente o ninho de seus jobs.*.steps.run Todas as listas de comando são concatenadas e verificadas como um script de shell.

• Os atributos shell são suportados
• Os valores e parâmetros do pipeline são ignorados e substituídos por variáveis ​​de concha de espaço reservado

Oleodutos Gitlab CI

Os arquivos GitLab CI têm mais estrutura e tentamos suportar mais.

• script , before_script , after_script : O GitLab não possui um, mas três atributos diferentes de script de shell que são lidos como três scripts independentes. No GitLab before_script e script são concatenados e executados em um único processo de shell, enquanto after_script sempre inicia um novo processo de shell. Isso tem algumas implicações para visibilidade variável etc. e é ignorado nesta ferramenta.
• include não é suportado, todo arquivo YAML é analisado por conta própria. Para pipelines grandes com muitos inclui, você pode usar outras ferramentas para resolver tudo e executar yaml_shellcheck no arquivo YAML mesclado.
• !reference é semi-suportada, lemos apenas a tag e inserimos um espaço reservado para não quebrar a análise YAML (TODO, deve ser simples de melhorar).
• decidiu não apoiar variables ​​verificando. shellcheck verifica as variáveis ​​de caso inferior para atribuições antes do uso, mas assume que todos os nomes de variáveis ​​de casos superiores são fornecidos externamente. -Os trabalhos IMHO Gitlab CI devem seguir essa convenção e usar nomes de variáveis ​​de casos superiores para variáveis ​​de CI/CD.

Ansible

O suporte Ansible é limitado. Esta ferramenta lê arquivos de manual ou tarefa de Ansible com listas da YAML.

Até agora, reconhece três tipos de elementos de lista:

• Tarefas usando o módulo shell (ou ansible.builtin.shell ).
• Elementos de manual, contendo um atributo tasks .
• Blocos ( block ) para listas de tarefas aninhadas.
• As expressões Jinja ( {{ ... }} ) são ignoradas e substituídas por variáveis ​​de shell de espaço reservado.

Comum

Os arquivos são lidos com um analisador YAML, para que todas as âncoras da YAML sejam resolvidas. Não há verificação adicional nos tipos ou estrutura de dados.

Após o uso do Bitbucket/GitLab, um bloco de script pode conter uma string ou uma matriz de strings.