问题
Recently code containing a debugging override was release to production. The code was clearly marked
// TODO - Remove before releasing to production
But we have nothing integrated into Maven that would prevent the project from building. I've seen a maven plugin called Taglist that produces a report. But won't stop produce a build error.
How do you guys catch debugging code and prevent builds?
回答1:
You could configure a maven checkstyle plugin to fail the build if it find TODO comments in your code.
To get checkstyle to fail a build
To get checkstyle to fail a build I followed the advice of this answer to a similar question: https://stackoverflow.com/a/42276077/7421645 they found they needed to add the configuration <violationSeverity>warning</violationSeverity> and the TodoComment needs to include a regex format property to Fail the build.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.17</version>
<dependencies>
<dependency>
<groupId>com.puppycrawl.tools</groupId>
<artifactId>checkstyle</artifactId>
<version>7.5.1</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>validate</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<logViolationsToConsole>true</logViolationsToConsole>
<checkstyleRules>
<module name="Checker">
<module name="TreeWalker">
<module name="TodoComment">
<property name="format" value="(TODO)"/>
</module>
</module>
</module>
</checkstyleRules>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failOnViolation>true</failOnViolation>
<failsOnError>true</failsOnError>
<violationSeverity>warning</violationSeverity>
</configuration>
</execution>
</executions>
</plugin>
You can also include more checks by choosing a pre-built checkstyle.xml
Always run checkstyle, but only fail if the profile is activated -Pci-build
To run:
mvn clean install -Pci-build
If you were using checkstyle, I'd expect you would want to gather more value from it than just checking for TODO comments. It doesn't look like you can configure multiple checkstyle configurations, e.g. inline and a configLocation for a Jenkins build job. But if you modify a checkstyle.xml that is suitable for your project, you can modify the severity of modules that you want to be errors:
<module name="TodoComment">
<property name="severity" value="error"/>
<property name="format" value="(TODO)|(FIXME)"/>
</module>
And you can use a property to turn on failure when you want, e.g. for server builds but not local in your maven pom.xml:
<properties>
<fail.on.error>false</fail.on.error>
</properties>
<profiles>
<profile>
<id>ci-build</id>
<properties>
<fail.on.error>true</fail.on.error>
</properties>
</profile>
</profiles>
And then you can use that as a property in your build config:
<configuration>
<configLocation>my_google_checks.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failOnViolation>false</failOnViolation>
<failsOnError>${fail.on.error}</failsOnError>
<violationSeverity>warning</violationSeverity>
</configuration>
I changed the failOnViolation to false to allow warnings in the checkstyle config to occur. And I'm using a modified version of the google checkstyle, but there is no reason why you couldn't apply the same with the inline config if you only wanted to check for TODO or a few other things.
This approach of failing on a builder server can be turned on when the profile "ci-build" is passed to maven.
When the ci-build profile isn't sent, checkstyle still runs, but just produces a report. Of course you could set it up so it still failed on anything style concerns that we deemed worthy of an error.
Only run checkstyle if the profile is activate -Pci-build
To run:
mvn clean install -Pci-build
In this case, you don't want checkstyle to run at all by default. So we just activate the checkstyle build profile when we want it.
<profiles>
<profile>
<id>ci-build</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.17</version>
<dependencies>
<dependency>
<groupId>com.puppycrawl.tools</groupId>
<artifactId>checkstyle</artifactId>
<version>7.5.1</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>validate</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<configLocation>my_google_checks.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failOnViolation>true</failOnViolation>
<failsOnError>true</failsOnError>
<violationSeverity>warning</violationSeverity>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
回答2:
I'm using maven checkstyle plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.15</version>
<executions>
<execution>
<id>validate</id>
<phase>validate</phase>
<configuration>
<configLocation>src/main/resources/config/checkstyle.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failsOnError>false</failsOnError>
<linkXRef>false</linkXRef>
</configuration>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
The configuration file should contain a TodoComment module This will prevent from building a code with "TODO" comments inside. You can configure it so that it looks at other comment regexps, like "FIXME" or something. Here you have more details.
回答3:
You could use the following plugin to detect TODO and/or FIXME (or any other comment text you define) and mark the build as unstable or failed if any are found: Task Scanner Plugin
However this analysis would be performed after the code is pulled down so it would depend on how your move-to-production process is set up. This plugin would allow you to mark the build job as failed (once you add it as a post-build step) and you could then cancel any downstream jobs if TODO was detected. If your move-to-production job is downstream from this build job, this would solve your problem.
来源：https://stackoverflow.com/questions/42403115/how-to-prevent-a-java-project-from-building-when-todo-present