Shell 脚本标准和风格指南
GitLab 包含许多不同的服务和子项目。它们的大部分后端代码是用 Ruby 和 Go 编写的。然而，其中一些使用 shell 脚本来自动化常规的系统管理任务，如部署、安装等。这样做要么是出于历史原因，要么是为了最小化依赖，例如 Docker 镜像。
本页旨在根据我们的各种经验来定义和组织我们的 shell 脚本指南。GitLab 项目中的所有 shell 脚本最终都应与此指南保持一致。如果任何项目与此指南有偏差，应在相应项目的 README.md 或 PROCESS.md 文件中进行说明。
避免使用 shell 脚本
这是必读章节。
综上所述，我们建议尽可能避免使用 shell 脚本。像 Ruby 或 Python 这样的语言（如果需要与我们使用的代码库保持一致性）几乎总是更好的选择。高级解释型语言具有更易读的语法，并为单元测试、代码检查和错误报告提供了更成熟的功能。
仅在项目依赖大小有严格限制，或在特定情况下有其他更重要要求时，才使用 shell 脚本。
本指南的范围
根据 GitLab 安装要求，本指南仅涵盖受支持的 Linux 发行版使用的 shell，即：
Shell 语言选择
- 当你需要减少依赖列表时，使用环境提供的工具。例如，对于 Docker 镜像，使用
alpine提供的sh，这是我们大多数工具镜像的基础镜像。 - 在其他所有地方，尽可能使用
bash。它比sh更强大，但仍是一个广泛使用的 shell。
代码风格和格式
本节描述了如果项目包含 shell 脚本，应使其成为项目 CI 管道强制组成部分的工具。这些工具可以自动化 shell 代码格式化、错误或漏洞检查等。
代码检查
我们使用默认配置的 ShellCheck 工具来检查我们的 shell 脚本。
所有包含 shell 脚本的项目都应使用这个 GitLab CI/CD 作业：
shell check:
image: koalaman/shellcheck-alpine:stable
stage: test
before_script:
- shellcheck --version
script:
- shellcheck scripts/**/*.sh # path to your shell scripts默认情况下，ShellCheck 使用 shell 检测
来确定使用的 shell 方言。如果 shell 文件不在你的控制范围内，且 ShellCheck 无法检测到方言，
请使用 -s 标志来指定：-s sh 或 -s bash。
格式化
建议使用 shfmt 工具来保持一致的格式。我们根据 Google Shell 风格指南 来格式化 shell 脚本，
因此应将以下 shfmt 命令应用于项目的脚本文件：
shfmt -i 2 -ci -w scripts/**/*.sh除了 代码检查 GitLab CI/CD 作业外，所有包含 shell 脚本的项目还应使用此作业：
shfmt:
image: mvdan/shfmt:v3.2.0-alpine
stage: test
before_script:
- shfmt -version
script:
- shfmt -i 2 -ci -d scripts # path to your shell scripts默认情况下，shfmt 使用类似于 ShellCheck 的 shell 检测，
并忽略以点开头的文件。要覆盖此行为，请使用 -ln 标志来指定 shell 方言：
-ln posix 或 -ln bash。
测试
此部分仍在进行中。
我们正在持续评估用于 shell 脚本自动化测试的不同工具（如 BATS），这是一个 正在进行的工作。
代码审查
代码审查应根据以下标准进行：
然而，推荐的做法是使用上述工具并解决报告的问题。这应该可以消除代码审查的需要。