使用 Pre-commit Hooks 现代化 Drupal 工作流

Source: Dev.to

问题

在为一家跨三大洲拥有众多开发者的庞大政府间公司管理 Drupal 发行版时，代码审查已无法成为防止语法错误的第一道防线。当高级架构师审查 Pull Request 时，已经太晚，无法再争论缩进或缺失的 docblock。

在一个自定义上游（CHG0099785）中，CI 流水线因琐碎的 PHPCS（PHP CodeSniffer）违规而持续失败，导致合并周期出现巨大瓶颈。一个制表符而不是两个空格就会让 CI 流水线花费 5–10 分钟启动容器、运行测试，最终在语法检查时失败。

将 10 分钟的等待时间乘以 20 位每天提交三次的开发者，意味着每周有数百小时被用于等待 Jenkins/GitLab 报告缺失的分号。

解决方案

将验证逻辑从远程 CI 服务器转移到开发者本地机器，使用自动化的 Git pre‑commit hooks。

• 在项目根目录的 package.json 中集成 husky 和 lint‑staged。
• 该钩子拦截 git commit 命令，仅针对当前在 Git 中暂存的文件进行处理。
• 检查整个遗留的 Drupal 核心需要几分钟；检查开发者刚编辑的两个文件只需约 400 毫秒。

实现

Pre‑commit Hook 工作流

1. 对暂存的文件运行 phpcbf（PHP Code Beautifier and Fixer）。

   • 如果开发者使用了双引号而不是单引号，phpcbf 会立即修正文件，重新暂存修正后的版本，并让提交悄然继续。

2. 在自动修复后运行 phpcs 以强制执行编码规范。

配置要点

// package.json (excerpt)
{
  "scripts": {
    "prepare": "husky install"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.php": [
      "phpcbf",
      "phpcs"
    ]
  }
}

下游部署

当下游供应商机构缺少必需的二进制文件（例如 Husky 所需的 Node.js）时出现了边缘情况。为了解决此问题，composer.json 的脚手架脚本被调整为在下游部署构建期间 禁用或绕过 严格的 pre‑commit 钩子，确保这些钩子仅对第一方 UI/UX 开发者生效，而对生产流水线保持透明。

结果

• 由于语法问题导致的 CI 失败率下降了 98 %。
• 高级架构师现在把时间花在审查业务逻辑和安全向量上，而不是在行长限制上发表评论。

参考

• 企业 CMS 案例研究：
• LinkedIn 个人资料：