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, ... )
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
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
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
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
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
Mark,
On Mon, Jan 14, 2013 at 12:13 PM, Mark Waite markwa...@yahoo.com 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,
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
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
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
10 matches
Mail list logo
