You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Kevin Gann <ka...@gmail.com> on 2009/08/07 17:34:01 UTC
Ivy feedback mechanisms for spawning builds...
I'm trying to figure out how to tell my CI system in an elegant way that an
artifact published to my Ivy repository has changed. Right now I
artificially give this feedback using Hudson which forces a build to be
executed once a library is published which a project is dependent on. To me
this looks very like bad practice, but I'm uncertain of the toolset
available to me.
Any feedback is appreciated.
Re: Ivy feedback mechanisms for spawning builds...
Posted by Kevin Gann <ka...@gmail.com>.
Yes. This is exactly what I was asking for is best practices. Tthis isn't
really an Ivy problem, but using Ivy definitely exposes the need for
thinking about the problem and managing it.
On Fri, Aug 7, 2009 at 10:41 AM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> I think what is being asked is how to enhance the CI system so that not
> only does it detect changes to the SCM system (which would obviously require
> a rebuild), but to also detect changes in that module's dependencies in the
> repository since a change in a dependency should also require a rebuild. So
> what methods or best practices have been developed to have a CI system check
> if a module's dependencies have changed since last time it was built to
> cause a rebuild?
>
> This might be more of a "pull" technique. The "push" technique might be
> more of what was already stated in this thread of having an extra step at
> the end of a build to automatically trigger any other module that has a
> dependency on the module just built.
>
> ---
> Shawn Castrianni
>
> -----Original Message-----
> From: Mitch Gitman [mailto:mgitman@gmail.com]
> Sent: Friday, August 07, 2009 11:53 AM
> To: ivy-user@ant.apache.org
> Subject: Re: Ivy feedback mechanisms for spawning builds...
>
> OK, I understand what's going on now. One thing to keep in mind is the
> distinction between upstream/dependency projects and downstream/dependent
> projects. Obviously, an ivy.xml tells you only about its dependencies. My
> understanding, though, (and I could be wrong about this) is that the Hudson
> Ivy plugin is able to figure out the downstream path. I'd asked about as
> much in this thread and got an affirmative:
>
> http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
>
> Frankly, I haven't found much value in having a plugin automatically figure
> out which projects to build once one project has built. I've been fine to
> do
> that manually. But I recognize some people may find value in that.
>
> On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Chris.Hilton@zilliant.com
> >wrote:
>
> > I can't tell if you've considered this already, but have you looked at
> the
> > Ivy plugin for Hudson?
> >
> > http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
> >
> > Apparently it looks at an ivy file in a project and handles building
> > dependencies, though I haven't tried it.
> >
> > Chris
> >
> > > -----Original Message-----
> > > From: Kevin Gann [mailto:kaygee@gmail.com]
> > > Sent: Friday, 07 August, 2009 11:38
> > > To: ivy-user@ant.apache.org
> > > Subject: Re: Ivy feedback mechanisms for spawning builds...
> > >
> > > Maybe I mis-understood but... I've built the model that you illustrate.
> > > :)
> > >
> > > version control system commit --> CI server build --> Ivy publish to
> > > shared
> > > repository
> > >
> > > The problem comes with other projects within VCS which I'd like rebuilt
> > > because a new artifact has been published. With my current knowledge I
> > > could
> > > configure Hudson to use a "build trigger" and build after another build
> > > takes place and utilize latest.integration (or similar) for the
> > > revision.
> > >
> > > Like I said... it feels wrong to have Hudson hold that configuration,
> > > but I
> > > suppose if CI is only monitoring VCS how else would it know? A hack
> > > would be
> > > to have CI monitor the share which holds the artifacts I want to
> > > rebuild
> > > with.
> > >
> > > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com>
> wrote:
> > >
> > > > Kevin, it sounds like you're thinking about the problem in the wrong
> > > way.
> > > > Leaving aside the case of the Ivysvn resolver where Subversion is
> > > doubling
> > > > as an Ivy resolver, your CI server should really be the party
> > > responsible
> > > > for publishing to your shared Ivy repository. The thing that's
> > > triggering
> > > > the CI server is commits to the version control system. This is the
> > > typical
> > > > relationship because it works and makes sense.
> > > >
> > > > Illustrated like so:
> > > > version control system commit --> CI server build --> Ivy publish to
> > > shared
> > > > repository
> > > >
> > > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com> wrote:
> > > >
> > > > > I'm trying to figure out how to tell my CI system in an elegant way
> > > that
> > > > an
> > > > > artifact published to my Ivy repository has changed. Right now I
> > > > > artificially give this feedback using Hudson which forces a build
> > > to be
> > > > > executed once a library is published which a project is dependent
> > > on. To
> > > > me
> > > > > this looks very like bad practice, but I'm uncertain of the toolset
> > > > > available to me.
> > > > >
> > > > > Any feedback is appreciated.
> > > > >
> > > >
> >
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
>
Re: Ivy feedback mechanisms for spawning builds...
Posted by Kevin Gann <ka...@gmail.com>.
I switched this company from CruiseControl to Hudson when I started and
haven't looked back. I'll take a look at QB and Bamboo though for
familiarity.
On Fri, Aug 7, 2009 at 3:28 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> I don't want this email thread to turn into a CI server comparison, but we
> use QuickBuild2. I love it! However, it does not currently have any IVY
> integration yet, but it does have support for plugins. If you haven't
> looked at QuickBuild since they released the QB2 beta, you might want to
> give it another chance.
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Gareth Western [mailto:gareth@garethwestern.com]
> Sent: Friday, August 07, 2009 5:20 PM
> To: ivy-user@ant.apache.org
> Subject: Re: Ivy feedback mechanisms for spawning builds...
>
> We use Atlassian Bamboo for our CI server. Bamboo does have a rather basic
> mechanism for specifying "child" and "parent" builds for each build plan,
> however it has no knowledge of the ivy.xml configuration files,
> unfortunately. Also, it does have a few shortcomings though, such as not
> being able to work out an optimal build order [1].
> For now we don't use Bamboo for our release builds, but instead have a
> separate Ant script which just builds each module in the correct order.
>
> [1] http://forums.atlassian.com/message.jspa?messageID=257281517
>
> <http://forums.atlassian.com/message.jspa?messageID=257281517>
>
> On Fri, Aug 7, 2009 at 9:10 PM, Joshua Tharp <
> joshua-tharp@alumni.calpoly.edu> wrote:
>
> > I use the Hudson Ivy plugin, and it does figure out both the upstream
> > and downstream dependencies from the ivy.XML files. What it doesn't do
> > (or at least I haven't figured it out yet) is not build a module when
> > you have multiple dependencies that all lead to the same one. For
> > example, if C depends on A and B and B also depends on A, then when A
> > is updated Hudson will likely build C twice (once when A is complete
> > and again when B is rebuilt.
> >
> > On Friday, August 7, 2009, Shawn Castrianni
> > <Sh...@halliburton.com> wrote:
> > > I think what is being asked is how to enhance the CI system so that not
> > only does it detect changes to the SCM system (which would obviously
> require
> > a rebuild), but to also detect changes in that module's dependencies in
> the
> > repository since a change in a dependency should also require a rebuild.
> So
> > what methods or best practices have been developed to have a CI system
> check
> > if a module's dependencies have changed since last time it was built to
> > cause a rebuild?
> > >
> > > This might be more of a "pull" technique. The "push" technique might
> be
> > more of what was already stated in this thread of having an extra step at
> > the end of a build to automatically trigger any other module that has a
> > dependency on the module just built.
> > >
> > > ---
> > > Shawn Castrianni
> > >
> > > -----Original Message-----
> > > From: Mitch Gitman [mailto:mgitman@gmail.com]
> > > Sent: Friday, August 07, 2009 11:53 AM
> > > To: ivy-user@ant.apache.org
> > > Subject: Re: Ivy feedback mechanisms for spawning builds...
> > >
> > > OK, I understand what's going on now. One thing to keep in mind is the
> > > distinction between upstream/dependency projects and
> downstream/dependent
> > > projects. Obviously, an ivy.xml tells you only about its dependencies.
> My
> > > understanding, though, (and I could be wrong about this) is that the
> > Hudson
> > > Ivy plugin is able to figure out the downstream path. I'd asked about
> as
> > > much in this thread and got an affirmative:
> > >
> >
> http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
> > >
> > > Frankly, I haven't found much value in having a plugin automatically
> > figure
> > > out which projects to build once one project has built. I've been fine
> to
> > do
> > > that manually. But I recognize some people may find value in that.
> > >
> > > On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <
> Chris.Hilton@zilliant.com
> > >wrote:
> > >
> > >> I can't tell if you've considered this already, but have you looked at
> > the
> > >> Ivy plugin for Hudson?
> > >>
> > >> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
> > >>
> > >> Apparently it looks at an ivy file in a project and handles building
> > >> dependencies, though I haven't tried it.
> > >>
> > >> Chris
> > >>
> > >> > -----Original Message-----
> > >> > From: Kevin Gann [mailto:kaygee@gmail.com]
> > >> > Sent: Friday, 07 August, 2009 11:38
> > >> > To: ivy-user@ant.apache.org
> > >> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> > >> >
> > >> > Maybe I mis-understood but... I've built the model that you
> > illustrate.
> > >> > :)
> > >> >
> > >> > version control system commit --> CI server build --> Ivy publish to
> > >> > shared
> > >> > repository
> > >> >
> > >> > The problem comes with other projects within VCS which I'd like
> > rebuilt
> > >> > because a new artifact has been published. With my current knowledge
> I
> > >> > could
> > >> > configure Hudson to use a "build trigger" and build after another
> > build
> > >> > takes place and utilize latest.integration (or similar) for the
> > >> > revision.
> > >> >
> > >> > Like I said... it feels wrong to have Hudson hold that
> configuration,
> > >> > but I
> > >> > suppose if CI is only monitoring VCS how else would it know? A hack
> > >> > would be
> > >> > to have CI monitor the share which holds the artifacts I want to
> > >> > rebuild
> > >> > with.
> > >> >
> > >> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com>
> > wrote:
> > >> >
> > >> > > Kevin, it sounds like you're thinking about the problem in the
> wrong
> > >> > way.
> > >> > > Leaving aside the case of the Ivysvn resolver where Subversion is
> > >> > doubling
> > >> > > as an Ivy resolver, your CI server should really be the party
> > >> > responsible
> > >> > > for publishing to your shared Ivy repository. The thing that's
> > >> > triggering
> > >> > > the CI server is commits to the version control system. This is
> the
> > >> > typical
> > >> > > relationship because it works and makes sense.
> > >> > >
> > >> > > Illustrated like so:
> > >> > > version control system commit --> CI server build --> Ivy publish
> to
> > >> > shared
> > >> > > repository
> > >> > >
> > >> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com>
> > wrote:
> > >> > >
> > >> > > > I'm trying to figure out how to tell my CI system in an elegant
> > way
> > >> > that
> > >> > > an
> > >> > > > artifact published to my Ivy repository has changed. Right now I
> > >> > > > artificially give this feedback using Hudson which forces a
> build
> > >> > to be
> > >> > > > executed once a library is published which a project
> > ----------------------------------------------------------------------
> > > This e-mail, including any attached files, may contain confidential and
> > privileged information for the sole use of the intended recipient. Any
> > review, use, distribution, or disclosure by others is strictly
> prohibited.
> > If you are not the intended recipient (or authorized to receive
> information
> > for the intended recipient), please contact the sender by reply e-mail
> and
> > delete all copies of this message.
> > >
> >
>
RE: Ivy feedback mechanisms for spawning builds...
Posted by Shawn Castrianni <Sh...@halliburton.com>.
I don't want this email thread to turn into a CI server comparison, but we use QuickBuild2. I love it! However, it does not currently have any IVY integration yet, but it does have support for plugins. If you haven't looked at QuickBuild since they released the QB2 beta, you might want to give it another chance.
---
Shawn Castrianni
-----Original Message-----
From: Gareth Western [mailto:gareth@garethwestern.com]
Sent: Friday, August 07, 2009 5:20 PM
To: ivy-user@ant.apache.org
Subject: Re: Ivy feedback mechanisms for spawning builds...
We use Atlassian Bamboo for our CI server. Bamboo does have a rather basic
mechanism for specifying "child" and "parent" builds for each build plan,
however it has no knowledge of the ivy.xml configuration files,
unfortunately. Also, it does have a few shortcomings though, such as not
being able to work out an optimal build order [1].
For now we don't use Bamboo for our release builds, but instead have a
separate Ant script which just builds each module in the correct order.
[1] http://forums.atlassian.com/message.jspa?messageID=257281517
<http://forums.atlassian.com/message.jspa?messageID=257281517>
On Fri, Aug 7, 2009 at 9:10 PM, Joshua Tharp <
joshua-tharp@alumni.calpoly.edu> wrote:
> I use the Hudson Ivy plugin, and it does figure out both the upstream
> and downstream dependencies from the ivy.XML files. What it doesn't do
> (or at least I haven't figured it out yet) is not build a module when
> you have multiple dependencies that all lead to the same one. For
> example, if C depends on A and B and B also depends on A, then when A
> is updated Hudson will likely build C twice (once when A is complete
> and again when B is rebuilt.
>
> On Friday, August 7, 2009, Shawn Castrianni
> <Sh...@halliburton.com> wrote:
> > I think what is being asked is how to enhance the CI system so that not
> only does it detect changes to the SCM system (which would obviously require
> a rebuild), but to also detect changes in that module's dependencies in the
> repository since a change in a dependency should also require a rebuild. So
> what methods or best practices have been developed to have a CI system check
> if a module's dependencies have changed since last time it was built to
> cause a rebuild?
> >
> > This might be more of a "pull" technique. The "push" technique might be
> more of what was already stated in this thread of having an extra step at
> the end of a build to automatically trigger any other module that has a
> dependency on the module just built.
> >
> > ---
> > Shawn Castrianni
> >
> > -----Original Message-----
> > From: Mitch Gitman [mailto:mgitman@gmail.com]
> > Sent: Friday, August 07, 2009 11:53 AM
> > To: ivy-user@ant.apache.org
> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >
> > OK, I understand what's going on now. One thing to keep in mind is the
> > distinction between upstream/dependency projects and downstream/dependent
> > projects. Obviously, an ivy.xml tells you only about its dependencies. My
> > understanding, though, (and I could be wrong about this) is that the
> Hudson
> > Ivy plugin is able to figure out the downstream path. I'd asked about as
> > much in this thread and got an affirmative:
> >
> http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
> >
> > Frankly, I haven't found much value in having a plugin automatically
> figure
> > out which projects to build once one project has built. I've been fine to
> do
> > that manually. But I recognize some people may find value in that.
> >
> > On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Chris.Hilton@zilliant.com
> >wrote:
> >
> >> I can't tell if you've considered this already, but have you looked at
> the
> >> Ivy plugin for Hudson?
> >>
> >> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
> >>
> >> Apparently it looks at an ivy file in a project and handles building
> >> dependencies, though I haven't tried it.
> >>
> >> Chris
> >>
> >> > -----Original Message-----
> >> > From: Kevin Gann [mailto:kaygee@gmail.com]
> >> > Sent: Friday, 07 August, 2009 11:38
> >> > To: ivy-user@ant.apache.org
> >> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >> >
> >> > Maybe I mis-understood but... I've built the model that you
> illustrate.
> >> > :)
> >> >
> >> > version control system commit --> CI server build --> Ivy publish to
> >> > shared
> >> > repository
> >> >
> >> > The problem comes with other projects within VCS which I'd like
> rebuilt
> >> > because a new artifact has been published. With my current knowledge I
> >> > could
> >> > configure Hudson to use a "build trigger" and build after another
> build
> >> > takes place and utilize latest.integration (or similar) for the
> >> > revision.
> >> >
> >> > Like I said... it feels wrong to have Hudson hold that configuration,
> >> > but I
> >> > suppose if CI is only monitoring VCS how else would it know? A hack
> >> > would be
> >> > to have CI monitor the share which holds the artifacts I want to
> >> > rebuild
> >> > with.
> >> >
> >> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com>
> wrote:
> >> >
> >> > > Kevin, it sounds like you're thinking about the problem in the wrong
> >> > way.
> >> > > Leaving aside the case of the Ivysvn resolver where Subversion is
> >> > doubling
> >> > > as an Ivy resolver, your CI server should really be the party
> >> > responsible
> >> > > for publishing to your shared Ivy repository. The thing that's
> >> > triggering
> >> > > the CI server is commits to the version control system. This is the
> >> > typical
> >> > > relationship because it works and makes sense.
> >> > >
> >> > > Illustrated like so:
> >> > > version control system commit --> CI server build --> Ivy publish to
> >> > shared
> >> > > repository
> >> > >
> >> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com>
> wrote:
> >> > >
> >> > > > I'm trying to figure out how to tell my CI system in an elegant
> way
> >> > that
> >> > > an
> >> > > > artifact published to my Ivy repository has changed. Right now I
> >> > > > artificially give this feedback using Hudson which forces a build
> >> > to be
> >> > > > executed once a library is published which a project
> ----------------------------------------------------------------------
> > This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
> >
>
Re: Ivy feedback mechanisms for spawning builds...
Posted by Gareth Western <ga...@garethwestern.com>.
We use Atlassian Bamboo for our CI server. Bamboo does have a rather basic
mechanism for specifying "child" and "parent" builds for each build plan,
however it has no knowledge of the ivy.xml configuration files,
unfortunately. Also, it does have a few shortcomings though, such as not
being able to work out an optimal build order [1].
For now we don't use Bamboo for our release builds, but instead have a
separate Ant script which just builds each module in the correct order.
[1] http://forums.atlassian.com/message.jspa?messageID=257281517
<http://forums.atlassian.com/message.jspa?messageID=257281517>
On Fri, Aug 7, 2009 at 9:10 PM, Joshua Tharp <
joshua-tharp@alumni.calpoly.edu> wrote:
> I use the Hudson Ivy plugin, and it does figure out both the upstream
> and downstream dependencies from the ivy.XML files. What it doesn't do
> (or at least I haven't figured it out yet) is not build a module when
> you have multiple dependencies that all lead to the same one. For
> example, if C depends on A and B and B also depends on A, then when A
> is updated Hudson will likely build C twice (once when A is complete
> and again when B is rebuilt.
>
> On Friday, August 7, 2009, Shawn Castrianni
> <Sh...@halliburton.com> wrote:
> > I think what is being asked is how to enhance the CI system so that not
> only does it detect changes to the SCM system (which would obviously require
> a rebuild), but to also detect changes in that module's dependencies in the
> repository since a change in a dependency should also require a rebuild. So
> what methods or best practices have been developed to have a CI system check
> if a module's dependencies have changed since last time it was built to
> cause a rebuild?
> >
> > This might be more of a "pull" technique. The "push" technique might be
> more of what was already stated in this thread of having an extra step at
> the end of a build to automatically trigger any other module that has a
> dependency on the module just built.
> >
> > ---
> > Shawn Castrianni
> >
> > -----Original Message-----
> > From: Mitch Gitman [mailto:mgitman@gmail.com]
> > Sent: Friday, August 07, 2009 11:53 AM
> > To: ivy-user@ant.apache.org
> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >
> > OK, I understand what's going on now. One thing to keep in mind is the
> > distinction between upstream/dependency projects and downstream/dependent
> > projects. Obviously, an ivy.xml tells you only about its dependencies. My
> > understanding, though, (and I could be wrong about this) is that the
> Hudson
> > Ivy plugin is able to figure out the downstream path. I'd asked about as
> > much in this thread and got an affirmative:
> >
> http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
> >
> > Frankly, I haven't found much value in having a plugin automatically
> figure
> > out which projects to build once one project has built. I've been fine to
> do
> > that manually. But I recognize some people may find value in that.
> >
> > On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Chris.Hilton@zilliant.com
> >wrote:
> >
> >> I can't tell if you've considered this already, but have you looked at
> the
> >> Ivy plugin for Hudson?
> >>
> >> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
> >>
> >> Apparently it looks at an ivy file in a project and handles building
> >> dependencies, though I haven't tried it.
> >>
> >> Chris
> >>
> >> > -----Original Message-----
> >> > From: Kevin Gann [mailto:kaygee@gmail.com]
> >> > Sent: Friday, 07 August, 2009 11:38
> >> > To: ivy-user@ant.apache.org
> >> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >> >
> >> > Maybe I mis-understood but... I've built the model that you
> illustrate.
> >> > :)
> >> >
> >> > version control system commit --> CI server build --> Ivy publish to
> >> > shared
> >> > repository
> >> >
> >> > The problem comes with other projects within VCS which I'd like
> rebuilt
> >> > because a new artifact has been published. With my current knowledge I
> >> > could
> >> > configure Hudson to use a "build trigger" and build after another
> build
> >> > takes place and utilize latest.integration (or similar) for the
> >> > revision.
> >> >
> >> > Like I said... it feels wrong to have Hudson hold that configuration,
> >> > but I
> >> > suppose if CI is only monitoring VCS how else would it know? A hack
> >> > would be
> >> > to have CI monitor the share which holds the artifacts I want to
> >> > rebuild
> >> > with.
> >> >
> >> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com>
> wrote:
> >> >
> >> > > Kevin, it sounds like you're thinking about the problem in the wrong
> >> > way.
> >> > > Leaving aside the case of the Ivysvn resolver where Subversion is
> >> > doubling
> >> > > as an Ivy resolver, your CI server should really be the party
> >> > responsible
> >> > > for publishing to your shared Ivy repository. The thing that's
> >> > triggering
> >> > > the CI server is commits to the version control system. This is the
> >> > typical
> >> > > relationship because it works and makes sense.
> >> > >
> >> > > Illustrated like so:
> >> > > version control system commit --> CI server build --> Ivy publish to
> >> > shared
> >> > > repository
> >> > >
> >> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com>
> wrote:
> >> > >
> >> > > > I'm trying to figure out how to tell my CI system in an elegant
> way
> >> > that
> >> > > an
> >> > > > artifact published to my Ivy repository has changed. Right now I
> >> > > > artificially give this feedback using Hudson which forces a build
> >> > to be
> >> > > > executed once a library is published which a project
> ----------------------------------------------------------------------
> > This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
> >
>
Re: Ivy feedback mechanisms for spawning builds...
Posted by Joshua Tharp <jo...@alumni.calpoly.edu>.
You only need to deal with the Ivy section of the project
configuration. The documentation
is deceptive on that point. At first it won't appear that it has had
any effect, but as the modules are built the plugin examines the
ivy.xml file and inserts the dependencies on the various other
projects.
On Friday, August 7, 2009, Kevin Gann <ka...@gmail.com> wrote:
> Joshua,
>
> I took a quick tour of the plugin... is it simply the check-box and defining
> the location of the ivy file? The instructions on the Hudson page show the
> "Build other projects" checked as well.
>
> On Fri, Aug 7, 2009 at 1:10 PM, Joshua Tharp <
> joshua-tharp@alumni.calpoly.edu> wrote:
>
>> I use the Hudson Ivy plugin, and it does figure out both the upstream
>> and downstream dependencies from the ivy.XML files. What it doesn't do
>> (or at least I haven't figured it out yet) is not build a module when
>> you have multiple dependencies that all lead to the same one. For
>> example, if C depends on A and B and B also depends on A, then when A
>> is updated Hudson will likely build C twice (once when A is complete
>> and again when B is rebuilt.
>>
>> On Friday, August 7, 2009, Shawn Castrianni
>> <Sh...@halliburton.com> wrote:
>> > I think what is being asked is how to enhance the CI system so that not
>> only does it detect changes to the SCM system (which would obviously require
>> a rebuild), but to also detect changes in that module's dependencies in the
>> repository since a change in a dependency should also require a rebuild. So
>> what methods or best practices have been developed to have a CI system check
>> if a module's dependencies have changed since last time it was built to
>> cause a rebuild?
>> >
>> > This might be more of a "pull" technique. The "push" technique might be
>> more of what was already stated in this thread of having an extra step at
>> the end of a build to automatically trigger any other module that has a
>> dependency on the module just built.
>> >
>> > ---
>> > Shawn Castrianni
>> >
>> > -----Original Message-----
>> > From: Mitch Gitman [mailto:mgitman@gmail.com]
>> > Sent: Friday, August 07, 2009 11:53 AM
>> > To: ivy-user@ant.apache.org
>> > Subject: Re: Ivy feedback mechanisms for spawning builds...
>> >
>> > OK, I understand what's going on now. One thing to keep in mind is the
>> > distinction between upstream/dependency projects and downstream/dependent
>> > projects. Obviously, an ivy.xml tells you only about its dependencies. My
>> > understanding, though, (and I could be wrong about this) is that the
>> Hudson
>> > Ivy plugin is able to figure out the downstream path. I'd asked about as
>> > much in this thread and got an affirmative:
>> >
>> http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
>> >
>> > Frankly, I haven't found much value in having a plugin automatically
>> figure
>> > out which projects to build once one project has built. I've been fine to
>> do
>> > that manually. But I recognize some people may find value in that.
>> >
>> > On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Chris.Hilton@zilliant.com
>> >wrote:
>> >
>> >> I can't tell if you've considered this already, but have you looked at
>> the
>> >> Ivy plugin for Hudson?
>> >>
>> >> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
>> >>
>> >> Apparently it looks at an ivy file in a project and handles building
>> >> dependencies, though I haven't tried it.
>> >>
>> >> Chris
>> >>
>> >> > -----Original Message-----
>> >> > From: Kevin Gann [mailto:kaygee@gmail.com]
>> >> > Sent: Friday, 07 August, 2009 11:38
>> >> > To: ivy-user@ant.apache.org
>> >> > Subject: Re: Ivy feedback mechanisms for spawning builds...
>> >> >
>> >> > Maybe I mis-understood but... I've built the model that you
>> illustrate.
>> >> > :)
>> >> >
>> >> > version control system commit --> CI server build --> Ivy publish to
>> >> > shared
>> >> > repository
>> >> >
>> >> > The pro
Re: Ivy feedback mechanisms for spawning builds...
Posted by Kevin Gann <ka...@gmail.com>.
Joshua,
I took a quick tour of the plugin... is it simply the check-box and defining
the location of the ivy file? The instructions on the Hudson page show the
"Build other projects" checked as well.
On Fri, Aug 7, 2009 at 1:10 PM, Joshua Tharp <
joshua-tharp@alumni.calpoly.edu> wrote:
> I use the Hudson Ivy plugin, and it does figure out both the upstream
> and downstream dependencies from the ivy.XML files. What it doesn't do
> (or at least I haven't figured it out yet) is not build a module when
> you have multiple dependencies that all lead to the same one. For
> example, if C depends on A and B and B also depends on A, then when A
> is updated Hudson will likely build C twice (once when A is complete
> and again when B is rebuilt.
>
> On Friday, August 7, 2009, Shawn Castrianni
> <Sh...@halliburton.com> wrote:
> > I think what is being asked is how to enhance the CI system so that not
> only does it detect changes to the SCM system (which would obviously require
> a rebuild), but to also detect changes in that module's dependencies in the
> repository since a change in a dependency should also require a rebuild. So
> what methods or best practices have been developed to have a CI system check
> if a module's dependencies have changed since last time it was built to
> cause a rebuild?
> >
> > This might be more of a "pull" technique. The "push" technique might be
> more of what was already stated in this thread of having an extra step at
> the end of a build to automatically trigger any other module that has a
> dependency on the module just built.
> >
> > ---
> > Shawn Castrianni
> >
> > -----Original Message-----
> > From: Mitch Gitman [mailto:mgitman@gmail.com]
> > Sent: Friday, August 07, 2009 11:53 AM
> > To: ivy-user@ant.apache.org
> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >
> > OK, I understand what's going on now. One thing to keep in mind is the
> > distinction between upstream/dependency projects and downstream/dependent
> > projects. Obviously, an ivy.xml tells you only about its dependencies. My
> > understanding, though, (and I could be wrong about this) is that the
> Hudson
> > Ivy plugin is able to figure out the downstream path. I'd asked about as
> > much in this thread and got an affirmative:
> >
> http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
> >
> > Frankly, I haven't found much value in having a plugin automatically
> figure
> > out which projects to build once one project has built. I've been fine to
> do
> > that manually. But I recognize some people may find value in that.
> >
> > On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Chris.Hilton@zilliant.com
> >wrote:
> >
> >> I can't tell if you've considered this already, but have you looked at
> the
> >> Ivy plugin for Hudson?
> >>
> >> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
> >>
> >> Apparently it looks at an ivy file in a project and handles building
> >> dependencies, though I haven't tried it.
> >>
> >> Chris
> >>
> >> > -----Original Message-----
> >> > From: Kevin Gann [mailto:kaygee@gmail.com]
> >> > Sent: Friday, 07 August, 2009 11:38
> >> > To: ivy-user@ant.apache.org
> >> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >> >
> >> > Maybe I mis-understood but... I've built the model that you
> illustrate.
> >> > :)
> >> >
> >> > version control system commit --> CI server build --> Ivy publish to
> >> > shared
> >> > repository
> >> >
> >> > The problem comes with other projects within VCS which I'd like
> rebuilt
> >> > because a new artifact has been published. With my current knowledge I
> >> > could
> >> > configure Hudson to use a "build trigger" and build after another
> build
> >> > takes place and utilize latest.integration (or similar) for the
> >> > revision.
> >> >
> >> > Like I said... it feels wrong to have Hudson hold that configuration,
> >> > but I
> >> > suppose if CI is only monitoring VCS how else would it know? A hack
> >> > would be
> >> > to have CI monitor the share which holds the artifacts I want to
> >> > rebuild
> >> > with.
> >> >
> >> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com>
> wrote:
> >> >
> >> > > Kevin, it sounds like you're thinking about the problem in the wrong
> >> > way.
> >> > > Leaving aside the case of the Ivysvn resolver where Subversion is
> >> > doubling
> >> > > as an Ivy resolver, your CI server should really be the party
> >> > responsible
> >> > > for publishing to your shared Ivy repository. The thing that's
> >> > triggering
> >> > > the CI server is commits to the version control system. This is the
> >> > typical
> >> > > relationship because it works and makes sense.
> >> > >
> >> > > Illustrated like so:
> >> > > version control system commit --> CI server build --> Ivy publish to
> >> > shared
> >> > > repository
> >> > >
> >> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com>
> wrote:
> >> > >
> >> > > > I'm trying to figure out how to tell my CI system in an elegant
> way
> >> > that
> >> > > an
> >> > > > artifact published to my Ivy repository has changed. Right now I
> >> > > > artificially give this feedback using Hudson which forces a build
> >> > to be
> >> > > > executed once a library is published which a project
> ----------------------------------------------------------------------
> > This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
> >
>
Re: Ivy feedback mechanisms for spawning builds...
Posted by Joshua Tharp <jo...@alumni.calpoly.edu>.
I use the Hudson Ivy plugin, and it does figure out both the upstream
and downstream dependencies from the ivy.XML files. What it doesn't do
(or at least I haven't figured it out yet) is not build a module when
you have multiple dependencies that all lead to the same one. For
example, if C depends on A and B and B also depends on A, then when A
is updated Hudson will likely build C twice (once when A is complete
and again when B is rebuilt.
On Friday, August 7, 2009, Shawn Castrianni
<Sh...@halliburton.com> wrote:
> I think what is being asked is how to enhance the CI system so that not only does it detect changes to the SCM system (which would obviously require a rebuild), but to also detect changes in that module's dependencies in the repository since a change in a dependency should also require a rebuild. So what methods or best practices have been developed to have a CI system check if a module's dependencies have changed since last time it was built to cause a rebuild?
>
> This might be more of a "pull" technique. The "push" technique might be more of what was already stated in this thread of having an extra step at the end of a build to automatically trigger any other module that has a dependency on the module just built.
>
> ---
> Shawn Castrianni
>
> -----Original Message-----
> From: Mitch Gitman [mailto:mgitman@gmail.com]
> Sent: Friday, August 07, 2009 11:53 AM
> To: ivy-user@ant.apache.org
> Subject: Re: Ivy feedback mechanisms for spawning builds...
>
> OK, I understand what's going on now. One thing to keep in mind is the
> distinction between upstream/dependency projects and downstream/dependent
> projects. Obviously, an ivy.xml tells you only about its dependencies. My
> understanding, though, (and I could be wrong about this) is that the Hudson
> Ivy plugin is able to figure out the downstream path. I'd asked about as
> much in this thread and got an affirmative:
> http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
>
> Frankly, I haven't found much value in having a plugin automatically figure
> out which projects to build once one project has built. I've been fine to do
> that manually. But I recognize some people may find value in that.
>
> On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Ch...@zilliant.com>wrote:
>
>> I can't tell if you've considered this already, but have you looked at the
>> Ivy plugin for Hudson?
>>
>> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
>>
>> Apparently it looks at an ivy file in a project and handles building
>> dependencies, though I haven't tried it.
>>
>> Chris
>>
>> > -----Original Message-----
>> > From: Kevin Gann [mailto:kaygee@gmail.com]
>> > Sent: Friday, 07 August, 2009 11:38
>> > To: ivy-user@ant.apache.org
>> > Subject: Re: Ivy feedback mechanisms for spawning builds...
>> >
>> > Maybe I mis-understood but... I've built the model that you illustrate.
>> > :)
>> >
>> > version control system commit --> CI server build --> Ivy publish to
>> > shared
>> > repository
>> >
>> > The problem comes with other projects within VCS which I'd like rebuilt
>> > because a new artifact has been published. With my current knowledge I
>> > could
>> > configure Hudson to use a "build trigger" and build after another build
>> > takes place and utilize latest.integration (or similar) for the
>> > revision.
>> >
>> > Like I said... it feels wrong to have Hudson hold that configuration,
>> > but I
>> > suppose if CI is only monitoring VCS how else would it know? A hack
>> > would be
>> > to have CI monitor the share which holds the artifacts I want to
>> > rebuild
>> > with.
>> >
>> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com> wrote:
>> >
>> > > Kevin, it sounds like you're thinking about the problem in the wrong
>> > way.
>> > > Leaving aside the case of the Ivysvn resolver where Subversion is
>> > doubling
>> > > as an Ivy resolver, your CI server should really be the party
>> > responsible
>> > > for publishing to your shared Ivy repository. The thing that's
>> > triggering
>> > > the CI server is commits to the version control system. This is the
>> > typical
>> > > relationship because it works and makes sense.
>> > >
>> > > Illustrated like so:
>> > > version control system commit --> CI server build --> Ivy publish to
>> > shared
>> > > repository
>> > >
>> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com> wrote:
>> > >
>> > > > I'm trying to figure out how to tell my CI system in an elegant way
>> > that
>> > > an
>> > > > artifact published to my Ivy repository has changed. Right now I
>> > > > artificially give this feedback using Hudson which forces a build
>> > to be
>> > > > executed once a library is published which a project ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
>
RE: Ivy feedback mechanisms for spawning builds...
Posted by Shawn Castrianni <Sh...@halliburton.com>.
I think what is being asked is how to enhance the CI system so that not only does it detect changes to the SCM system (which would obviously require a rebuild), but to also detect changes in that module's dependencies in the repository since a change in a dependency should also require a rebuild. So what methods or best practices have been developed to have a CI system check if a module's dependencies have changed since last time it was built to cause a rebuild?
This might be more of a "pull" technique. The "push" technique might be more of what was already stated in this thread of having an extra step at the end of a build to automatically trigger any other module that has a dependency on the module just built.
---
Shawn Castrianni
-----Original Message-----
From: Mitch Gitman [mailto:mgitman@gmail.com]
Sent: Friday, August 07, 2009 11:53 AM
To: ivy-user@ant.apache.org
Subject: Re: Ivy feedback mechanisms for spawning builds...
OK, I understand what's going on now. One thing to keep in mind is the
distinction between upstream/dependency projects and downstream/dependent
projects. Obviously, an ivy.xml tells you only about its dependencies. My
understanding, though, (and I could be wrong about this) is that the Hudson
Ivy plugin is able to figure out the downstream path. I'd asked about as
much in this thread and got an affirmative:
http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
Frankly, I haven't found much value in having a plugin automatically figure
out which projects to build once one project has built. I've been fine to do
that manually. But I recognize some people may find value in that.
On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Ch...@zilliant.com>wrote:
> I can't tell if you've considered this already, but have you looked at the
> Ivy plugin for Hudson?
>
> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
>
> Apparently it looks at an ivy file in a project and handles building
> dependencies, though I haven't tried it.
>
> Chris
>
> > -----Original Message-----
> > From: Kevin Gann [mailto:kaygee@gmail.com]
> > Sent: Friday, 07 August, 2009 11:38
> > To: ivy-user@ant.apache.org
> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >
> > Maybe I mis-understood but... I've built the model that you illustrate.
> > :)
> >
> > version control system commit --> CI server build --> Ivy publish to
> > shared
> > repository
> >
> > The problem comes with other projects within VCS which I'd like rebuilt
> > because a new artifact has been published. With my current knowledge I
> > could
> > configure Hudson to use a "build trigger" and build after another build
> > takes place and utilize latest.integration (or similar) for the
> > revision.
> >
> > Like I said... it feels wrong to have Hudson hold that configuration,
> > but I
> > suppose if CI is only monitoring VCS how else would it know? A hack
> > would be
> > to have CI monitor the share which holds the artifacts I want to
> > rebuild
> > with.
> >
> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com> wrote:
> >
> > > Kevin, it sounds like you're thinking about the problem in the wrong
> > way.
> > > Leaving aside the case of the Ivysvn resolver where Subversion is
> > doubling
> > > as an Ivy resolver, your CI server should really be the party
> > responsible
> > > for publishing to your shared Ivy repository. The thing that's
> > triggering
> > > the CI server is commits to the version control system. This is the
> > typical
> > > relationship because it works and makes sense.
> > >
> > > Illustrated like so:
> > > version control system commit --> CI server build --> Ivy publish to
> > shared
> > > repository
> > >
> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com> wrote:
> > >
> > > > I'm trying to figure out how to tell my CI system in an elegant way
> > that
> > > an
> > > > artifact published to my Ivy repository has changed. Right now I
> > > > artificially give this feedback using Hudson which forces a build
> > to be
> > > > executed once a library is published which a project is dependent
> > on. To
> > > me
> > > > this looks very like bad practice, but I'm uncertain of the toolset
> > > > available to me.
> > > >
> > > > Any feedback is appreciated.
> > > >
> > >
>
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
Re: Ivy feedback mechanisms for spawning builds...
Posted by Mitch Gitman <mg...@gmail.com>.
OK, I understand what's going on now. One thing to keep in mind is the
distinction between upstream/dependency projects and downstream/dependent
projects. Obviously, an ivy.xml tells you only about its dependencies. My
understanding, though, (and I could be wrong about this) is that the Hudson
Ivy plugin is able to figure out the downstream path. I'd asked about as
much in this thread and got an affirmative:
http://www.nabble.com/trying-to-configure-the-Hudson-Ivy-plugin-td22530817.html
Frankly, I haven't found much value in having a plugin automatically figure
out which projects to build once one project has built. I've been fine to do
that manually. But I recognize some people may find value in that.
On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Ch...@zilliant.com>wrote:
> I can't tell if you've considered this already, but have you looked at the
> Ivy plugin for Hudson?
>
> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
>
> Apparently it looks at an ivy file in a project and handles building
> dependencies, though I haven't tried it.
>
> Chris
>
> > -----Original Message-----
> > From: Kevin Gann [mailto:kaygee@gmail.com]
> > Sent: Friday, 07 August, 2009 11:38
> > To: ivy-user@ant.apache.org
> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >
> > Maybe I mis-understood but... I've built the model that you illustrate.
> > :)
> >
> > version control system commit --> CI server build --> Ivy publish to
> > shared
> > repository
> >
> > The problem comes with other projects within VCS which I'd like rebuilt
> > because a new artifact has been published. With my current knowledge I
> > could
> > configure Hudson to use a "build trigger" and build after another build
> > takes place and utilize latest.integration (or similar) for the
> > revision.
> >
> > Like I said... it feels wrong to have Hudson hold that configuration,
> > but I
> > suppose if CI is only monitoring VCS how else would it know? A hack
> > would be
> > to have CI monitor the share which holds the artifacts I want to
> > rebuild
> > with.
> >
> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com> wrote:
> >
> > > Kevin, it sounds like you're thinking about the problem in the wrong
> > way.
> > > Leaving aside the case of the Ivysvn resolver where Subversion is
> > doubling
> > > as an Ivy resolver, your CI server should really be the party
> > responsible
> > > for publishing to your shared Ivy repository. The thing that's
> > triggering
> > > the CI server is commits to the version control system. This is the
> > typical
> > > relationship because it works and makes sense.
> > >
> > > Illustrated like so:
> > > version control system commit --> CI server build --> Ivy publish to
> > shared
> > > repository
> > >
> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com> wrote:
> > >
> > > > I'm trying to figure out how to tell my CI system in an elegant way
> > that
> > > an
> > > > artifact published to my Ivy repository has changed. Right now I
> > > > artificially give this feedback using Hudson which forces a build
> > to be
> > > > executed once a library is published which a project is dependent
> > on. To
> > > me
> > > > this looks very like bad practice, but I'm uncertain of the toolset
> > > > available to me.
> > > >
> > > > Any feedback is appreciated.
> > > >
> > >
>
Re: Ivy feedback mechanisms for spawning builds...
Posted by Kevin Gann <ka...@gmail.com>.
Chris,
I haven't seen this plugin. Interesting concept... looks better than manual
triggers through Hudson and hacking building by monitoring VCS.
On Fri, Aug 7, 2009 at 9:41 AM, Hilton, Chris <Ch...@zilliant.com>wrote:
> I can't tell if you've considered this already, but have you looked at the
> Ivy plugin for Hudson?
>
> http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
>
> Apparently it looks at an ivy file in a project and handles building
> dependencies, though I haven't tried it.
>
> Chris
>
> > -----Original Message-----
> > From: Kevin Gann [mailto:kaygee@gmail.com]
> > Sent: Friday, 07 August, 2009 11:38
> > To: ivy-user@ant.apache.org
> > Subject: Re: Ivy feedback mechanisms for spawning builds...
> >
> > Maybe I mis-understood but... I've built the model that you illustrate.
> > :)
> >
> > version control system commit --> CI server build --> Ivy publish to
> > shared
> > repository
> >
> > The problem comes with other projects within VCS which I'd like rebuilt
> > because a new artifact has been published. With my current knowledge I
> > could
> > configure Hudson to use a "build trigger" and build after another build
> > takes place and utilize latest.integration (or similar) for the
> > revision.
> >
> > Like I said... it feels wrong to have Hudson hold that configuration,
> > but I
> > suppose if CI is only monitoring VCS how else would it know? A hack
> > would be
> > to have CI monitor the share which holds the artifacts I want to
> > rebuild
> > with.
> >
> > On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com> wrote:
> >
> > > Kevin, it sounds like you're thinking about the problem in the wrong
> > way.
> > > Leaving aside the case of the Ivysvn resolver where Subversion is
> > doubling
> > > as an Ivy resolver, your CI server should really be the party
> > responsible
> > > for publishing to your shared Ivy repository. The thing that's
> > triggering
> > > the CI server is commits to the version control system. This is the
> > typical
> > > relationship because it works and makes sense.
> > >
> > > Illustrated like so:
> > > version control system commit --> CI server build --> Ivy publish to
> > shared
> > > repository
> > >
> > > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com> wrote:
> > >
> > > > I'm trying to figure out how to tell my CI system in an elegant way
> > that
> > > an
> > > > artifact published to my Ivy repository has changed. Right now I
> > > > artificially give this feedback using Hudson which forces a build
> > to be
> > > > executed once a library is published which a project is dependent
> > on. To
> > > me
> > > > this looks very like bad practice, but I'm uncertain of the toolset
> > > > available to me.
> > > >
> > > > Any feedback is appreciated.
> > > >
> > >
>
RE: Ivy feedback mechanisms for spawning builds...
Posted by "Hilton, Chris" <Ch...@zilliant.com>.
I can't tell if you've considered this already, but have you looked at the Ivy plugin for Hudson?
http://wiki.hudson-ci.org/display/HUDSON/Ivy+Plugin
Apparently it looks at an ivy file in a project and handles building dependencies, though I haven't tried it.
Chris
> -----Original Message-----
> From: Kevin Gann [mailto:kaygee@gmail.com]
> Sent: Friday, 07 August, 2009 11:38
> To: ivy-user@ant.apache.org
> Subject: Re: Ivy feedback mechanisms for spawning builds...
>
> Maybe I mis-understood but... I've built the model that you illustrate.
> :)
>
> version control system commit --> CI server build --> Ivy publish to
> shared
> repository
>
> The problem comes with other projects within VCS which I'd like rebuilt
> because a new artifact has been published. With my current knowledge I
> could
> configure Hudson to use a "build trigger" and build after another build
> takes place and utilize latest.integration (or similar) for the
> revision.
>
> Like I said... it feels wrong to have Hudson hold that configuration,
> but I
> suppose if CI is only monitoring VCS how else would it know? A hack
> would be
> to have CI monitor the share which holds the artifacts I want to
> rebuild
> with.
>
> On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com> wrote:
>
> > Kevin, it sounds like you're thinking about the problem in the wrong
> way.
> > Leaving aside the case of the Ivysvn resolver where Subversion is
> doubling
> > as an Ivy resolver, your CI server should really be the party
> responsible
> > for publishing to your shared Ivy repository. The thing that's
> triggering
> > the CI server is commits to the version control system. This is the
> typical
> > relationship because it works and makes sense.
> >
> > Illustrated like so:
> > version control system commit --> CI server build --> Ivy publish to
> shared
> > repository
> >
> > On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com> wrote:
> >
> > > I'm trying to figure out how to tell my CI system in an elegant way
> that
> > an
> > > artifact published to my Ivy repository has changed. Right now I
> > > artificially give this feedback using Hudson which forces a build
> to be
> > > executed once a library is published which a project is dependent
> on. To
> > me
> > > this looks very like bad practice, but I'm uncertain of the toolset
> > > available to me.
> > >
> > > Any feedback is appreciated.
> > >
> >
Re: Ivy feedback mechanisms for spawning builds...
Posted by Kevin Gann <ka...@gmail.com>.
Maybe I mis-understood but... I've built the model that you illustrate. :)
version control system commit --> CI server build --> Ivy publish to shared
repository
The problem comes with other projects within VCS which I'd like rebuilt
because a new artifact has been published. With my current knowledge I could
configure Hudson to use a "build trigger" and build after another build
takes place and utilize latest.integration (or similar) for the revision.
Like I said... it feels wrong to have Hudson hold that configuration, but I
suppose if CI is only monitoring VCS how else would it know? A hack would be
to have CI monitor the share which holds the artifacts I want to rebuild
with.
On Fri, Aug 7, 2009 at 8:42 AM, Mitch Gitman <mg...@gmail.com> wrote:
> Kevin, it sounds like you're thinking about the problem in the wrong way.
> Leaving aside the case of the Ivysvn resolver where Subversion is doubling
> as an Ivy resolver, your CI server should really be the party responsible
> for publishing to your shared Ivy repository. The thing that's triggering
> the CI server is commits to the version control system. This is the typical
> relationship because it works and makes sense.
>
> Illustrated like so:
> version control system commit --> CI server build --> Ivy publish to shared
> repository
>
> On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com> wrote:
>
> > I'm trying to figure out how to tell my CI system in an elegant way that
> an
> > artifact published to my Ivy repository has changed. Right now I
> > artificially give this feedback using Hudson which forces a build to be
> > executed once a library is published which a project is dependent on. To
> me
> > this looks very like bad practice, but I'm uncertain of the toolset
> > available to me.
> >
> > Any feedback is appreciated.
> >
>
Re: Ivy feedback mechanisms for spawning builds...
Posted by Mitch Gitman <mg...@gmail.com>.
Kevin, it sounds like you're thinking about the problem in the wrong way.
Leaving aside the case of the Ivysvn resolver where Subversion is doubling
as an Ivy resolver, your CI server should really be the party responsible
for publishing to your shared Ivy repository. The thing that's triggering
the CI server is commits to the version control system. This is the typical
relationship because it works and makes sense.
Illustrated like so:
version control system commit --> CI server build --> Ivy publish to shared
repository
On Fri, Aug 7, 2009 at 8:34 AM, Kevin Gann <ka...@gmail.com> wrote:
> I'm trying to figure out how to tell my CI system in an elegant way that an
> artifact published to my Ivy repository has changed. Right now I
> artificially give this feedback using Hudson which forces a build to be
> executed once a library is published which a project is dependent on. To me
> this looks very like bad practice, but I'm uncertain of the toolset
> available to me.
>
> Any feedback is appreciated.
>