用于 checkstyle 的 Svn 预提交钩子答案

【问题标题】：Svn pre-commit hook for checkstyle用于 checkstyle 的 Svn 预提交钩子
【发布时间】：2012-04-26 00:57:21
【问题描述】：

这是我当前的 checkstyle shell 脚本。如果我在 TRUNK 上提交而不是在 Branches 上提交，它工作正常。我真的不明白为什么它不起作用。有人可以帮我吗？

#!/bin/sh

###################################################
#
# Verify Checkstyle
#
###################################################

REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook
JAVA=/opt/ibm/java2-i386-50/bin/java
CHECKSTYLE=/usr/local/checkstyle/checkstyle-all-5.1.jar
TMPDIR=/tmp/$TXN
REPORT=/tmp/$TXN/report
CHECKSTYLE_CONFIG=/usr/local/checkstyle/checkstyle.xml

CHANGED=`$SVNLOOK changed -t "$TXN" "$REPOS" | grep -v "^D" | awk '{print $2}'`
mkdir -p $TMPDIR
for LINE in $CHANGED ; do
    FILE=`echo $LINE | egrep -v Test\\.java$ | egrep -v \\/src\\/test\\/ | egrep -v \\/js\\/ext`
    if [ -n "$FILE" ] ; then
        DIRNAME=`dirname $FILE`
        mkdir -p $TMPDIR/$DIRNAME
        $SVNLOOK cat $REPOS --transaction $TXN $FILE > $TMPDIR/$FILE
    fi
done
$JAVA -jar $CHECKSTYLE -c $CHECKSTYLE_CONFIG -r $TMPDIR > $TMPDIR/tmpfile.checkstyle
X=$?
if [ $X -ne 0 ] ; then
    cat $TMPDIR/tmpfile.checkstyle > /dev/stderr
    rm -Rf $TMPDIR
    exit 1
fi
rm -Rf $TMPDIR

exit 0

谢谢！

【问题讨论】：

标签： svn hook checkstyle pre-commit

【解决方案1】：

忠告：不要将此作为预提交脚本。

任何预提交脚本都会阻止提交直到完成。如果我签入十几个文件，该脚本运行需要多长时间？当我第一次接触计算时，第二秒的响应时间被认为是可以接受的。现在，如果您在几秒钟内没有得到回复，人们就会抱怨。
如果checkstyle 捕捉到一些不成问题的东西，或者开发人员编写它的方式实际上比checkstyle 坚持的内容更清晰、更容易理解，会发生什么？当您使用 checkstyle 或 findbugs 之类的内容时，您必须了解您会得到一些误报。

更好的方法是使用像Jenkins 这样的持续构建引擎。 Jenkins 可以设置为在每次提交时自动启动构建。詹金斯可以：

自动存储构建结果。然后，您实际上可以直接从 Jenkins 发布代码以供测试和为您的客户使用。毕竟，您知道您测试过的相同 jar/ear/war 文件与您的客户将获得的相同。
自动运行各种测试，包括：
- 检查样式
- 查找错误
- Corbertura
- PMD
- 干燥
- JUnit
- 检查内置警告
- 还有其他几十个
Jenkins 将整个构建输出、所有保存的工件和所有测试保存在一个美观且易于查看的网页中，任何用户都可以使用。
Jenkins 可以集成到各种问题跟踪工具中，因此您可以查看 Jenkins 构建的特定问题所涉及的内容。

您不必使用 Jenkins。哈德森还在。 CruiseControl 也是如此，您可以使用 TeamCity、Bamboo 和其他数十种持续构建系统。我喜欢 Jenkins，因为开发非常活跃，而且设置起来非常简单。在我第一次听说它时，我花了大约 30 分钟下载并运行我的第一份工作。

我知道你问过你的 pre-commit 钩子，我不想听起来像一个推销员（Jenkins 是免费和开源的，我与该项目没有任何联系），而是让事情变得像checkstyle 检查预提交挂钩是否自找麻烦。使用持续构建服务器只是处理此问题的更好方法。

【讨论】：

我不同意。我也使用和喜欢 Jenkins，但检查编码约定应该在提交完成之前完成。否则为时已晚，您的颠覆差异已经被无意义的格式更改搞砸了。这就是为什么，IMO，只有当代码满足你的风格要求时，提交才应该完成。
有两个问题：一个是时间。如果完成提交需要 5 到 10 秒，您的开发人员将执行更少的提交，这不是您想要的。二是违规误报。如果代码样式检查器返回错误违规怎么办？你不能提交代码，或者花 20 到 30 分钟尝试修改你的代码，直到工具满意？为开发人员提供在提交前进行检查的方法，并使用代码样式失败构建有太多违规行为。反向错误提交。开发人员将学习在提交之前进行代码样式检查，这将成为您文化的一部分。
首先，最好的做法是让提交尽可能小。检查 StyleCop 这样的工具可以让你在每个案例的基础上抑制错误和警告。
哦，我忘记了在构建过程中进行检查的最重要问题：提交后不能只检查修改过的文件。在现有项目中引入样式检查器时这是一个大问题，因为开发人员无法修复所有文件（甚至是项目/包中的所有文件）。当然，您也可以将违规视为警告而不是错误。但是开发人员会忽略这些，就像其他构建警告一样。（如果您与不同的人一起工作，请认为自己很幸运。）相反，我宁愿让开发人员只修复他修改的文件。 IMO 简单且有意义
我认为应该防止讨厌的提交（即使误报是一种风险）。关于“更少的提交”，我认为最好，理想情况下，我希望每个#issue 提交一个，而不是很多，涉及所有必要的更改来克服问题，以及与更改错误修复相关的微小提交。 +10 詹金斯推销员演讲哈哈

【解决方案2】：

提示。

尝试比较目录结构，创建临时目录（删除“rm -Rf $TMPDIR”）。

也许你在树干和树枝之间有区别，比如：

后备箱： /tmp/12/code/file.java

分支机构： /tmp/br1/12/code/file.java

【讨论】：