On Tue, May 28, 2013 at 2:03 PM, Jim Zajkowski <[email protected]> wrote:
>
> This is perhaps a bit outside the normal Jenkins setup, but I need to have a
> job run periodically, and that job will determine whether or not another job
> should be run.
>
> Right now I have this working by having the first job change a file and the
> second job trigger via FSTrigger.
>
> However, this doesn't work when using different nodes, because the FSTrigger
> monitors on the node assigned to the second job, not necessarily the first
> job.
>
> All the research I've found suggests doing one of two things:
>
> a. Have the monitoring job return success / fail depending on whether the
> second job should run, and use the normal downstream job mechanism. This
> seems less than ideal because the first job doesn't really /fail/ per se, it
> runs and makes a decision. To me, a failure means it couldn't make a
> decision one way or the other.
>
> b. Have the monitoring job invoke the second job via remote call, e.g., with
> curl. Our Jenkins installation is behind a centralized SSO system, so that
> makes life a bit more difficult, but not impossible.
>
> Is there any way to perhaps have a job execute based on the output of the
> monitoring job? Or any other way to do this?
The simplest change would be to put your FStrigger file on a netwrok
filesystem that the master and slaves can all access. Or set up a
similar approach with a central subversion respository where the slave
can update a file that the master will notice in the next poll. There
is some extra overhead involved, but you could include extra
information in the file and track the history of updates easily.
--
Les Mikesell
[email protected]
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.