SVN JSHint 钩子?

SVN JSHint Hook?

我一直在 Google 和此处搜索,但没有找到相关答案。我正在从事的项目正在使用 SVN。我的问题是想知道是否有人实现了一个预提交挂钩,如果 JSHint 失败,它将停止签入?

感谢任何有过类似经验的人。

由于 JSHint 花费的时间长,我不会将其设为预提交挂钩。当有人提交时,他们将不得不等待 JSHint 完成并等待判决。

记住 Subversion 挂钩 运行 在服务器上而不是客户端的机器上。这意味着您的预提交挂钩必须进行检查,然后 运行 JSHint。即使这只需要 30 秒来执行,开发人员也有 30 秒坐在那里等待提交完成,并且他们对你、公司和 Subversion 的仇恨越来越大。另外,如果钩子出现问题导致它失败,您将不得不调试并修复它,而开发人员将无法提交他们的代码。

您的开发人员会很快厌恶您和 Subversion,甚至可能采取建立自己的源代码库的步骤。在 ClearCase 统治和 Subversion 首次创建的日子里,我已经看到这样做了。开发人员使用 Subversion 设置他们自己的存储库(因为这很容易做到)并停止使用公司的 ClearCase 存储库。

不要使用预提交挂钩,而是使用像 Jenkins 这样的持续构建引擎。

当有人提交时,Jenkins 会进行检查,然后 运行 您需要的任何工具(例如 运行ning JSHint)。稍后,您可能想要扩展要使用的工具。您甚至可以让 Jenkins 创建一个可部署的工件(如 zip 文件)。 Jenkins 将收集您的历史记录,向您展示提交之间的更改,并让您知道谁做了什么更改。

但是,您会问,如果没有预提交挂钩,开发人员将无法签入导致 JSHint 失败的代码吗?

是的,他们可以。但是,您可以将 Jenkins 配置为在发生这种情况时通知您和开发人员。由于这是版本控制,因此很容易让开发人员修复问题或撤消他们的提交。

诀窍是羞辱 破坏构建 的开发人员。栅栏和熟透的西红柿供应很好。一顶笨拙的帽子和一个写着 "I broke the build" 的大标志也可以。也许一个大猩红色 B 缝在他们的衣服上。

实际上,开发人员自然不会希望破坏构建。这让他们看起来很糟糕而且不专业。开发人员将养成 运行 在提交之前自己使用 JSHint 的习惯,这正是您希望发生的事情。