> On May 15, 2014, 11:04 p.m., Maxim Khutornenko wrote: > > build.gradle, line 235 > > <https://reviews.apache.org/r/21455/diff/1/?file=581766#file581766line235> > > > > How about a custom target instead? Having something like "gradle > > build_cq" would be easier to remember for use outside of jenkins script. > > Jake Farrell wrote: > agree, think having these tied to a task would be better, maybe gradle > verify since check is part of the lifecycle all ready > > Bill Farner wrote: > Do either of you know how to express that? > > I see 2 fundamental approaches: > > - dynamically remove verification tasks when 'build' is being run > > This seems like an uphill battle, since we would need to know which tasks > the plugins are adding dependencies to, and remove them. Removing task > dependencies also seems to be frowned upon [1]. > > [1] http://forums.gradle.org/gradle/topics/how_to_remove_a_task_dependency > > - conditionally enable verification tasks when the 'verify' task is being > run > > The only implementation i have come up with is to figure out which task > gradle was invoked with, and set a flag if 'verify' was invoked. This has > shortcomings in that the 'verify' task cannot be extended with other tasks. > > > Overall, both of the above approaches seem to go against the grain of how > gradle is intended to work. Are there other approaches you guys are thinking > of? > > Maxim Khutornenko wrote: > The 'verify' inheritance shortcoming does not sound like a deal breaker. > I doubt the ability to extend it further would be vital (unless I am missing > something). > > If none of the above work any chance the '-PrunCodeQuality=true' could be > reduced to something shorter and easier to remember? I.e. a single letter > option '-q'? > > Bill Farner wrote: > > The 'verify' inheritance shortcoming does not sound like a deal breaker. > > If that were the only downside, i'd probably agree with you. But the > deal breaker comes with the additional downsides of dependency removal being > frowned upon by gradle developers, and the fact that we have to hunt through > the dependency graph to find where these tasks are attaching. I agree that > bundling this in a task is nice, but it feels like we might be asking for > more tooling battles if we take this approach. > > > could be reduced to something shorter and easier to remember? I.e. a > single letter option '-q' > > Not that i know of, have you found anything to suggest that you can? > > Maxim Khutornenko wrote: > This seems to be working just fine: gradle -Pq build. > > Bill Farner wrote: > Ah, i thought you wanted to drop the 'P'. > > > a single letter option '-q' > > Maxim Khutornenko wrote: > Sorry, the '-q' was just an example. All I wanted was to make it as short > as possible.
Changed to -Pq. Diff incoming. - Bill ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21455/#review43177 ----------------------------------------------------------- On May 14, 2014, 8:31 p.m., Bill Farner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21455/ > ----------------------------------------------------------- > > (Updated May 14, 2014, 8:31 p.m.) > > > Review request for Aurora and Maxim Khutornenko. > > > Repository: aurora > > > Description > ------- > > Inclusion of findbugs has had the side-effect of slowing down development > iteration. It makes sense to only perform code quality checks on-demand, so > we would typically do this in jenkins, before publishing a review diff, and > before pushing to master. > > > Diffs > ----- > > build-support/jenkins/build.sh f6f4940a1450cd0d8d8497e651d0e6c7377dfc3f > build.gradle f2c729e28b01c89e2130c48d2aa43d7c830528a5 > > Diff: https://reviews.apache.org/r/21455/diff/ > > > Testing > ------- > > Before this change: > > $ ./gradlew clean build > :clean > :about > :bootstrapThrift UP-TO-DATE > :generateSources > :compileGeneratedJava > :processGeneratedResources UP-TO-DATE > :generatedClasses > :compileJava > :processResources > :classes > :jar > :assemble > :checkstyleMain > :compileTestJava > :processTestResources > :testClasses > :checkstyleTest > :findbugsGenerated > :findbugsMain > :findbugsTest > :licenseGenerated UP-TO-DATE > :licenseMain UP-TO-DATE > :licenseTest UP-TO-DATE > :license UP-TO-DATE > :test > > BUILD SUCCESSFUL > > Total time: 9 mins 5.6 secs > > > After this change: > $ ./gradlew clean build > :clean > :about > :bootstrapThrift UP-TO-DATE > :generateSources > :compileGeneratedJava > :processGeneratedResources UP-TO-DATE > :generatedClasses > :compileJava > :processResources > :classes > :jar > :assemble > :checkstyleMain SKIPPED > :compileTestJava > :processTestResources > :testClasses > :checkstyleTest SKIPPED > :findbugsGenerated SKIPPED > :findbugsMain SKIPPED > :findbugsTest SKIPPED > :licenseGenerated SKIPPED > :licenseMain SKIPPED > :licenseTest SKIPPED > :license UP-TO-DATE > :test > > BUILD SUCCESSFUL > > Total time: 1 mins 41.661 secs > > > /gradlew -PrunCodeQuality=true clean build > Parallel execution is an incubating feature. > :clean > :about > :bootstrapThrift UP-TO-DATE > :generateSources > :compileGeneratedJava > :processGeneratedResources UP-TO-DATE > :generatedClasses > :compileJava > :processResources > :classes > :jar > :assemble > :checkstyleMain > :compileTestJava > :processTestResources > :testClasses > :checkstyleTest > :findbugsGenerated > :findbugsMain > :findbugsTest > :licenseGenerated UP-TO-DATE > :licenseMain UP-TO-DATE > :licenseTest UP-TO-DATE > :license UP-TO-DATE > :test > :jacocoTestReport > :check > :build > > BUILD SUCCESSFUL > > Total time: 6 mins 58.768 secs > > > Thanks, > > Bill Farner > >
