Hi,
On the theorical base, the dependencies should be the other way round.
The continuous integration principle is that dependencies should trigger
the build of the projects that uses these dependencies, not the other way
round...
But of course, there are always some cases that don't match such a
Faisal,
Thanks for your post.
The problem you face is a very common one. When I tried to implement a fix
for this a few year ago using Hudson, I was unable to do so using a purely
Hudson approach. I tried various approaches, such as using build quiet
times (as documented in the above posts).
I've sent my reply to the job-dsl-plugin group, which I must have missed
when searching for the right place to start this thread ;)
For anyone that might be following along at home, the new thread is over
here:
https://groups.google.com/forum/?fromgroups=#!topic/job-dsl-plugin/wajQbppRsX0
On S
Mark,
On Mon, Jan 14, 2013 at 12:13 PM, Mark Waite wrote:
> We used a different technique to accomplish the goal I believe you're
> trying to accomplish.
>
> Our first "smoke test" job was responsible to checkout the most recent
> submission. If the job was successful at the end, we placed a ta
We used a different technique to accomplish the goal I believe you're trying to
accomplish.
Our first "smoke test" job was responsible to checkout the most recent
submission. If the job was successful at the end, we placed a tag on the git
repository and pushed the tag (with --force) to the ce
Thanks for pointing it out, in this case the wiki has gone out of date.
I'll go update it. The documentation which is consistently updated with
each check-in the formal DSL Command page:
https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-DSL-Commands
And page's example is correct. Another sou
Node.toString isn't an exact representation of what is saved. Under the
covers, each dsl method and configure method just queue's up the closures
that need to be run to generate the xml. They are then played back once the
whole DSL has been run through. This all happens in Job.getXml(), so you'l
Hello Mark,
Thanks for your response. I'll investigate an 'Execute Shell' solution for
the moment.
The reason for wanting this ability is as part of our build pipeline.
I want to trigger the build of a project (which lives in its own git repo)
and once that project has built, trigger another pro
Adding a build step seems like it should work. I don't see a way from the
plugin settings to perform a point in time checkout or even to perform a
checkout of a specific SHA1.
Can you share why you want to take a point in time rather than the tip of a
branch? I'm curious about the use model a
I would like to automate the process of creating/removing views and jobs on a
running instance of jenkins from code. I imagined creating a java
application that uses the jenkins api to do various jenkins
(re)configuration tasks, eg. create jobs, specify scm, build types (maven,
free style, ... ) et
10 matches
Mail list logo
