Gradle plugin - automatically build dependencies

[Lars Hvile]

I'm thinking about making an enhancement to the Gradle plugin by making
it automatically set up a dependency graph between jobs, like the
maven/ivy plugins do. Anyone working on a similar feature? Any pitfalls
or recommended approaches?

--
Lars Hvile

[Grégory Boissinot]

I don't think it's a good idea. Jobs should be independent.

In my opinion, regarding the granularity between Jenkins jobs and Gradle projets/modules,  a job should match to a complete Gradle project and not a Gradle submodule.

Then, you are able to use trigger mechanisms such as the IvyTrigger plugin to trigger a new build according a new value of a version of an Ivy depndency (therefore a Gradle dependency).

[Lars Hvile]

>> I don't think it's a good idea. Jobs should be independent.

You mean like in general? Dependencies between jobs is a bad idea? My usecase is that I have something like 30+ jobs.
Some for common libraries and the rest for components in our system. These jobs clearly aren't independent at all, and I don't
want to manually maintain the dependencies in Jenkins. The maven plugin already fixes this for us.

>> In my opinion, regarding the granularity between Jenkins jobs and Gradle projets/modules, a job should match to a complete Gradle project and not a Gradle submodule.

I agree. This is possible with the maven plugin as well, and I'm in fact using it that way.

>> Then, you are able to use trigger mechanisms such as the IvyTrigger plugin to trigger a new build according a new value of a version of an Ivy depndency (therefore a Gradle dependency).

Didn't know about this. But does this mean that each project must have an ivy.xml for the dependencies, as well as the regular gradle stuff?

Lars Hvile

________________________________________
From: jenkin...@googlegroups.com [jenkin...@googlegroups.com] On Behalf Of Grégory Boissinot [gregory....@gmail.com]
Sent: Thursday, December 22, 2011 12:44 AM
To: jenkin...@googlegroups.com
Subject: Re: Gradle plugin - automatically build dependencies

I don't think it's a good idea. Jobs should be independent.
In my opinion, regarding the granularity between Jenkins jobs and Gradle projets/modules, a job should match to a complete Gradle project and not a Gradle submodule.
Then, you are able to use trigger mechanisms such as the IvyTrigger plugin to trigger a new build according a new value of a version of an Ivy depndency (therefore a Gradle dependency).

[Grégory Boissinot]

You're right.

My answer is in general use cases.

However, my solution is applicable in all cases.

Please look at the XTrigger plugin (https://wiki.jenkins-ci.org/display/JENKINS/XTrigger+Plugin).

In your case, you are able to use the IvyTrigger or the MavenTrigger plugin.

Jobs are triggered if there are new binaries  pushed in a binary repository. The binaries in the repository polled matches the dependency in your build descriptor (ivy.xml or pom.xml).

With this approach, you don't maintain any dependencies in Jenkins.

And after the MavenTrigger and IvyTrigger, there is need to have the GradleTrigger. Therefore, no additional ivy.xml in each job but just the original gradle descriptor.

[Lars Hvile]

XTrigger or something like it would get the job done I guess. But it
doesn't feel like a good enough replacement for explicit dependencies
within Jenkins to me..

What happens to the tracking? In my current setup I can trace a commit
from a shared library all the way into a packaged application. And all
that useless polling.. Just doesn't feel right. So either way I'm going
to use the dependency mechanisms within Jenkins, it would just be cool
if the Gradle plugin would help me maintain them.

As for the rest of your answer. The Maven plugin does this for me today,
but if I were to switch to gradle, I would have no use for the pom (or
ivy.xml). Thus, the IvyTrigger or MavenTrigger plugins wouldn't be able
to help me unless I kept redundant versions of ivy.xml or pom.xml
around. Or am I missing something here?

--
Lars Hvile

[Daniel L.]

I found this group while searching about the exact same problem that you are having. I agree that there should be a way to automatically trigger downstream jobs from the build.gradle instead of hacking something to use a generated ivy.xml or something like that. Do you have any update on this work? I saw that on a presentation from Grégory Boissinot (http://www.slideshare.net/gboissinot/jenkinsmeetup) that he was planning on doing a GradleTrigger plugin, if that help. Keep us posted about your work!