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)..
Related
I am trying to setup a jenkins server for the very first time. I have synced it to the Perforce server I use, and I have created a workspace for that. Now I would like jenkins to start building everytime a change is submited, I have been researching through the topics here, and I found this link: How to trigger a Jenkins build on a Perforce submit. But it mentions that in order to do that I have to create a script on the P4 server On the Perforce server, it is possible to create triggers or, in other words, scripts to be run on a particular event - for example after a change-commit., I do not know what it means to create a script on the P4 server. Does it mean I need to have physical access to the server? I am just connecting to a remote server. I am kinda lost here...
Ideally, you'd have access to be able to create a trigger. If you can't do that, the next best thing is to create a cron job or scheduled task (depending on your OS) to check to see if there is something new. I've run similar jobs to:
Run p4 sync -n to see if there is anything new
If there is something new, a) sync it and build it (your choice of everything, or you could write something that would test, say, the first changelist for which there is something new, then keep doing so changelist-by-changelist)
If there is already a build in progress, don't run.
My jobs were set to check every five minutes, but I even had a project where once/hour was enough.
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 occasionally want to get notified when a particular jenkins job that is building finishes. Is there any way to do this?
Scripting it through the API would be fine. I already have the jenkins IRC bot that notifies me of many things, so if I could just dynamically modify the running job build, that would be enough to do what I want -- I'm just having a hard time finding how to accomplish that.
AFAIK, you cannot change a job's config while it's running.
Here is an idea: Use a post-build step to check for an external resource status (like a file containing an action by text) and running an action based on the content of the file.
The external file can be modified while the build is running, so when the post-build is executed, it will follow the logic defined based on the content of the file.
I hope this helps.
You can use email notifier, It will send you an email
https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
I am using Jenkins in combination with the Git and Gerrit plugins. I would like to trigger a job on Ref Updated. However, I need to understand if the action behind this event is the creation of a new branch. If it is, then I will execute my shell script, otherwise not.
As far as I understood, this info is available in the Gerrit's event json response, but I do not know how to consume this json object via Jenkins in the first place.
Is there a way to achieve this easily via Jenkins (maybe something in the interface I missed)? Or is there another way to monitor the creation of a new branch while still in the Jenkins/Gerrit plugin environment?
So I just recalled there are a bunch of Gerrit environmental variables which are available to use in the building script,
namely these ones. I will just have to check if GERRIT_OLDREV is equal to 0000000000000000000000000000000000000000 and if so, it would mean the branch is newly created (for reference: here). Here is the picture I attached in full size.
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.