Hmm, I have to admit docs dont have my favor cause they are easily outdated and hard to search but you hit a good point. Starting by renaming properly the tasks and maybe writing what is done in build files - since it is code and even "api for dev", it requires as much comments than the main api - can be better to start.
Also a big switch flag to bypass checkstyle/findbugs/... can be good while in dev since these phases cost a looot for nothing while you validates your code in runners modules for instance. Le 23 janv. 2018 07:15, "Kenneth Knowles" <[email protected]> a écrit : On Mon, Jan 22, 2018 at 10:03 PM, Romain Manni-Bucau <[email protected]> wrote: > @Kenneth: why not dropping the doc for a script with comments in the > project? A "RUNME.sh" ;). > That's cool, too, but also any shell one liner can be a gradle one liner or mvn two/three liner :-). it is just trading one command that you cannot guess easily for a different one that you still can't guess easily. For example, are the SparkRunner ValidatesRunner tests in the SparkRunner or the core SDK or a third module that integrates the two? And why would you know that the example ITs are called "sparkRunnerPreCommit"? It doesn't even make sense really to have "precommit" or "postcommit" except as aliases to make it easy to repro Jenkins' behavior - they have no other intrinsic meaning. So I was proposing a mapping from "full sentence + description" to one liner to help people navigate the targets that we set up. Some web page or doc that people can just quickly scan to find out to do common things, easier than groovy or XML. Kenn
