Yep,
a compromise can be to ensure all custom tasks have a description maybe:
diff --git a/examples/java/build.gradle b/examples/java/build.gradle
index 0fc0b17df..001bd8b38 100644
--- a/examples/java/build.gradle
+++ b/examples/java/build.gradle
@@ -130,7 +130,7 @@ def preCommitAdditionalFlags = [
dataflowStreamingRunner: [ "--streaming=true" ],
]
for (String runner : preCommitRunners) {
- tasks.create(name: runner + "PreCommit", type: Test) {
+ tasks.create(name: runner + "PreCommit", type: Test, description: "Run
tests for runner ${runner.replace('Runner', '')}") {
def preCommitBeamTestPipelineOptions = [
"--project=apache-beam-testing",
"--tempRoot=gs://temp-storage-for-end-to-end-tests",
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>
2018-01-23 8:45 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> Hi Romain,
>
> I think we are pretty close: agree to add some explicit tasks & projects
> names.
>
> We can add additional tasks like skipAudit, for instance.
>
> As reminder, gradle tasks provides the list of tasks and gradle projects
> provides the list of projects/modules.
>
> Regards
> JB
>
> On 01/23/2018 08:12 AM, Romain Manni-Bucau wrote:
> > 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" <k...@google.com
> > <mailto:k...@google.com>> a écrit :
> >
> > On Mon, Jan 22, 2018 at 10:03 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > <mailto:rmannibu...@gmail.com>> 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
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
