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.
Related
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!
We use visual svn for version control. I have few cloud web servers where my websites are running.
I would like to create some repositories for the websites content. I checkout them in local editors (notepad ++), edit them and checkin to SVN. But when check-in to visualSVN, I would like them to get deployed to the webservers docroot. In some cases I would like to restart the webserver too.
Is it possible using Jenkins+deployment plugins. I am very new to jenkins, can somebody help me with some information how we can achieve this.
It is one of the scenarios Jenkins is designed for (Continuous Delivery, aka. CD). Your perfect plan might look like this:
Get a new instance of Jenkins up/running (for experiments) (if you're familiar with Docker it is one of the best ways to experiment with Jenkins);
Configure Subversion Plugin in Jenkins (integration with SVN);
Setup your first FreeStyle job in Jenkins that polls your Visual SVN server for changes (things you check-in to SVN) and learn how that works (* * * * * <~-
this polls changes from your source control an every minute, great for experiments);
Setup your second FreeStyle job that connects to one of your webservers (probably via SSH) and creates a file (simple "touch hello_world.log" is great to start with) in a special folder dedicated for that kind of tests (DO NOT MESS WITH YOUR PRODUCTUION CONTENT FOLDER(s));
Setup your third FreeStyle job that combines your experiences acquired in #1 and #2, and still writes to a test folder;
Compare results of the job output with your production deployment expectations (eq. files in place, content is processed the right way, configuration files are looking good and etc.);
Try it out on one of the production web servers, one folder/site at a time;
Apply your newly crafted delivery pipeline to the rest of servers/sites;
Learn how backup your Jenkins instance and actually make your first backup;
Try to restore your Jenkins instance from the backup made in the previous step;
Decide whether it is okay for you to maintain your own Jenkins instance or you will be better off with a hosted version of it (CloudBees Inc.);
Learn more about Pipeline in Jenkins and possibly (because it is not immediately obvious) migrate your FreeStyle job(s) to Pipeline DSL
and/or Jenkinsfile;
At times you might need to get back to "Get Started with Jenkins" manual and look up for the ideas or answers, it is okay - do not give up and feel free to post your questions here, at SO.
Hope these ideas will help you to get started.
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.
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)..
My Jenkins server is set up with two jobs A and B say.
Job A is triggered from changes in subversion, runs unit tests and if successful, creates a WAR and deploys it to another environment.
If Job A succeeds, then Job B triggers. This job runs tests against the deployed WAR.
The problem is that the deployment process takes a while and the WAR is not ready in time for when Job B starts and tries to use it.
I'm looking for ideas on how to delay Job B until the WAR is up and running.
Is there a way, once Job B is triggered to wait for x seconds? I really don't want to put it into the tests in Job B if I can avoid it.
Thanks
There is definitely a way for a job to wait - just put sleep into the first shell build step. Alternatively, you can set 'Quiet period' - it's in Advanced Project Options when you create a build.
That, however, is a band-aid solution to be employed only if other approaches fail. You may try the following: if there is a way to make the deployment process (that job A triggers) right before it finishes to touch a file that Jenkins has access to, then you can use FSTrigger Plugin. See use case 3 there.
The most reliable way to make this work would be to make job A not complete until the deployment is successful, e.g. by testing for a valid response from the URL of the deployed web app. This blog post describes one way to do that.