I had a request a to create a java client and start jenkins build for a specific job; and get back the result of that build.
The problem is, the system is used by multiple users and their build might messed up altogether. Also the get latest build my retrieve me the previous finished build instead of current one. Is there anyway to do build/get result transactionally?
I don't think there's a way to get true transactional functionality (in the way that, say, Postgres is transactional), however, I think you can prevent collisions amongst multiple users by doing the following:
Have your build wrapped around a script (bash, Python, or similar) which takes out an exclusive lock on a semfile before the build and releases it after its done. That is, a file which serves as a semaphore that the build process must be able to exclusively lock in order to be able to proceed.
That way, if you have a build in progress, and another user triggers one, the in-progress build will have the semfile locked, and the 2nd one will block waiting for the exclusive lock on that file, getting the lock only once the 1st build is complete and has released the lock on the file.
Also, to be able to refer to each remote build after the fact, I would recommend you refer to my previous post Retrieve id of remotely triggered jenkins job.
Related
How to submit the Jenkins job using curl api and get its buid number ?
Note - i tried with the following api, but its not printing any build number.
curl -X POST http://<hostname>:8080/job/<jobname>/build
In general, you can't do this: when you submit (or "trigger") a Jenkins job, this will not necessarily create and start a new build.
When triggering a job, only a request for starting a new build will enter the build queue. Depending on the availability of suitable executors, the actual build will be created (and started) immediately, later, or never at all. Also, multiple queued requests will normally be "squashed", so several submits will result in the same build number.
Bottom line: this can be done (with the constraints mentioned before), but it will require additional (Groovy) scripting for tracking the submit request through the build queue until the build will be started by Jenkins.
I'm trying to set up a build server for a process we're trying to automate, and have run into an issue that I'm hoping there's an easy fix (or plugin) for.
The end goal is to have a set of jobs that each check for changes in a small subset of our Perforce depot, and then perform a task. The issue is that each of these tasks requires the entire depot in order to execute properly, and since the depot is so large (30+GB) and there are so many of these tasks (50+), actually duplicating the depot and syncing it would be an extreme waste of disk space and network bandwidth.
Instead, I'd like to have one "master" job that deals with syncing the depot (which all the child jobs share), and then have each child job use their own workspace and the "Preview Check Only" populate option in the Jenkins Perforce plugin (which syncs with p4 sync -k). Each child job's workspace would then exist only for the job to be able to detect when changes it is interested in have happened, after which they would run their tasks from inside the "master" workspace depot, and everything should just work!
Except I have not been able to figure out how to trigger the child jobs AND have them check for changes to their local workspace before deciding to run. Is there any way to have the children run all the checks they would normally run (if they were just scheduled to run every once in a while) when triggered by another job?
Or maybe there's a better way to do what I'm trying to do? Something that would allow me to share a single Perforce depot, but have child jobs that only run when part of that depot changes? There will also be more child jobs created over time, so being able to set them up and configure them easily would also be a nice thing to have.
I finally figured out a solution here, but it's pretty convoluted. Here goes!
The master job does the Perforce sync, and then runs a batch script that uses curl to run a polling of each child job: curl -X POST http://jenkins/view/Job/polling. When the child jobs have Poll SCM enabled (but do not have a schedule set), this lets them poll the SCM when the receive the polling request from the web API. Kinda messy, but it works!
I have a build in Jenkins which has failed for a temporary reason. I'd like to just re-build it. On the website I just click "rebuild" (from the rebuild plug-in), and if it is a parameterized job, I get asked if I want to keep the parameters. Importantly, the new job contains a "rebuild" link back to the original job enabling back-tracing.
How can I effect this "rebuild" from the REST API. I have code that will get a completed job, extract the parameters, and invoke a new job with those same parameters - so I've got most of the way there.
But I don't know how to establish the rebuild link so I can trace what job is a rebuild of what other job.
You can't -- the rebuild plugin does not implement a REST API (as of current version 1.25; I just checked the sources).
If your job has no parameters, then just GETing the <buildUrl>/rebuild URL should trigger a rebuild, though.
If your job does have parameters, then some more scripting will be needed to mimick what you do manually in those two steps.
Is there a way to get the hudson job initiated user name.
Is it possible to get using script shell, py etc.
Lets assume I have the build # which was initiated. I know how to get the latest build info using api but would like to get a user details for a specific job.
Do you think, this will work for hudson? :)
https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin
Thanks in advance
That plugin will not work with Hudson, unless you download a very old version of the plugin. I'm not sure how many people are still using Hudson and haven't upgraded to Jenkins.
Anyway, when a user manually triggers a build, this is called a "user cause"; there are other types of cause, e.g. SCM trigger.
You can use the JSON or XML API to get the causes for a build, for example:
https://ci.jenkins-ci.org/job/remoting/lastSuccessfulBuild/api/xml?xpath=//action/cause/userId
In this case, this returns the username that caused the build to run.
Though note that there may be multiple causes for a build, and potentially other cause types that use the userId field.
This works in Jenkins, but it should also work in Hudson, but I haven't tested it.
I need to build in jenkins only if there has been any change in ClearCase stream. I want to check it also in nightly or when someone choose to build manually, and to stop the build completely if there are no changes.
I tried the poll SCM but it doesn't seem to work well...
Any suggestion?
If it is possible, you should monitor the update of a snapshot view and, if the log of said update reveal any new files loaded, trigger the Jnekins job.
You find a similar approach in this thread.
You don't want to do something like that in a checkin trigger. It runs on the users client and will slow tings down, not to mention that you'd somehow have to figure out how to give every client access to that snapshot view.
What can work is a cron or scheduled job that runs lshistory and does something when it finds new checkins.
Yes you could do this via trigger, but I'd suggest a combo of trigger and additional script.. since updating the snapshot view might be time-consuming and effect checkins...
Create a simple trigger that when the files you are concerned about are changed on a stream will fire..
The script should "touch/create" a file in some well-known network location (or perhaps write to a pipe)...
the other script could be some cron (unix) or AT (windows) job that runs continually or each minute and if the well-known file is there will perform the update of the snapshot view..
The script could also read the Pipe written to by the trigger if you go that route
This is better than a cron job that has to do an lshistory each time.. but Martina was right to suggest not doing the whole thing in a trigger for performance and snapshot view accessability for all clients.. but a trigger to write to a pipe or write some empty file is efficient and the cron/AT job that actually does the update is effieicnet as it does not have to query the VOB each minute... just the file (or only after there is info on the pipe)..