<\/p>\n
The fundamentals of Jenkins are straightforward, but there’s a significant gap between basics and practical, real-life use. Little material exists to bridge that gap.<\/p>\n
<\/p>\n
Here, then, are two examples meant for that exact purpose. You can skim them for the general idea or you can follow along line by line.<\/p>\n
<\/p>\n
<\/h3>\nProject 1: Version Control & Email Feedback<\/h3>\n
This example demonstrates some of Jenkins’ fine controls. It uses the Email Extension Plugin<\/strong>, which allows customization of Jenkins’ existing email abilities, along with some standard plugins such as the Git plugin.<\/p>\n <\/p>\n We’ll assume you have Git set up on your machine; if not, here’s some info on getting it set up<\/a>. The link is for CentOS 7 as that is what this example uses (if you’re using a different system, only minor adaptations should be necessary).<\/p>\n <\/p>\n Let’s set up a Git repository, and associate it with source code already existing in version control. To parallel this exact example, set up a repository on BitBucket<\/a>, a popular source control website (it’s free).<\/p>\n <\/p>\n On your machine, first install Apache server.<\/p>\n Then, install Git, replacing <name> and <email> with your name and email, respectively. The latter lines of this section simply set information in Git’s internal system so it knows who is writing what code.<\/p>\n Then, create a directory in the public webserve location and initialize a repository.<\/p>\n Depending on your user, you may now need to run the following to give yourself control of the location:<\/p>\n Now, let’s setup the code repository. Replace <remote code location> with the location of your repository. If you created a BitBucket repo, yours will follow a format of https:\/\/<username>@bitbucket.org\/<repo owner>\/<repo name>.git.<\/p>\n The echo<\/strong> command writes to a file, in this case contributors.txt. The git add<\/strong> command says to add all new files to the file tracking system that Git employs, git commit<\/strong> says you are done writing for now and the files you have edited are ready to be sent to the remote location, the central repo. Git push<\/strong> is what actually sends the files.<\/p>\n <\/p>\n So now our local code is linked up to the code on BitBucket (or wherever you have chosen to place your remote code).<\/p>\n <\/p>\n Next, create the new project! This follows the same basic steps as before, only this time, on the configuration page, we add a few changes. First, we select Git as our version control, which is available to us due to the plugin we previously installed. Specify your repo URL; in this case, mine is https:\/\/mberlove@bitbucket.org\/mberlove\/jenkinscontroltest.git.<\/p>\n <\/p>\n You will need to add credentials; for BitBucket, this is a simple user\/password pair.<\/p>\n <\/p>\n We also want to create a build trigger to tell Jenkins when to run — i.e. not just manually! In the Build Triggers<\/strong> section we check Poll SCM<\/strong> (that’s software configuration management<\/a>, meaning that Jenkins is going to check on the source control system to see if there are changes according to a schedule we’re about to specify).<\/p>\n In the Schedule<\/strong> box, we enter H\/5 * * * *<\/strong>. This means that Jenkins will poll the system every five minutes (the little question mark next to this box contains useful information on this field). We’ll add an “execute shell” build script to run<\/p>\n and then add a single post-build action: Editable E-mail Notification<\/strong>. If you’re following along, you can see that the fields here are auto-populated with default representative variables.<\/p>\n <\/p>\n Next, add yourself as a recipient in the project recipient list, replacing the existing variable. Click on Advanced Settings<\/strong> to reveal a number of new options, including the Triggers<\/strong> area, where you can control when and why an email gets sent. Add a new trigger and select Always<\/strong>, indicating Jenkins will send this email any time it runs this job, then save the configuration.<\/p>\n <\/p>\n Now, we can make a change in the code repository to trigger the Jenkins job. We’ll run the following to make a new file and then add it, commit it, and push it to the repo:<\/p>\n Wait a few minutes for the poll to happen…and sure enough, the following email is sent:<\/p>\n <\/p>\n Clicking on the link in the email brings us to the job run information page, which conveniently contains the record of my most recent commit!<\/p>\n And as always you can go to Console Output<\/strong> from here to see more details.<\/p>\n <\/p>\n You can also see the broad results of this and other jobs on the dashboard (Jenkins home):<\/p>\n <\/p>\n This next example has a good deal of grounding in the practical. It monitors specified files for comments marked “TODO.” This kind of comment pops up commonly in software projects, and it can indicate incomplete work, so even if a project compiles and functions, you may not want it considered “complete”, so you can set Jenkins to watch for this, and change the status of a build based on whether TODO comments are found in a file.<\/p>\n <\/p>\n As previously, start off with a new project. We’ll link it in to the same BitBucket project as before and give it the same polling schedule. However, this requires a new plugin, Jenkins Text Finder<\/strong>, which you can install the same way as previously shown. This provides the ability to search through files using regular expressions, and modify the outcome of a build based on the results of the search.<\/p>\n <\/p>\n Now add a new post-build step, selecting the Jenkins Text Finder<\/strong> option, which exposes a new form. Here you can set what files to search, the pattern for which to search, and what to do if they are found. We’ll set Jenkins to check just the file1<\/strong> file in the jenkinscontroltest directory, to look for “TODO”, and to set the build to unstable<\/strong> if this pattern is found.<\/p>\n The location of your file must be specified relative<\/em> to the Jenkins workspace for this job. In the example, it was necessary to ascend several levels in the directory from the user folder where Jenkins was operating.<\/p>\n <\/p>\n When this is configured, save the job configuration, and then make a change to the file and push:<\/p>\n A few minutes later, a job build shows up on the project page:<\/p>\n\n
sudo yum -y install httpd\r\nsudo service httpd restart<\/pre>\n<\/blockquote>\n
\n
sudo yum -y install git\r\nsudo git config --global user.name \"<name>\"\r\nsudo git config --global user.email \"<email>\"<\/pre>\n<\/blockquote>\n
\n
cd \/var\/www\/html\r\nsudo mkdir jenkinscontroltest<\/pre>\n<\/blockquote>\n
\n
sudo chown -R <user> jenkinscontroltest<\/pre>\n<\/blockquote>\n
\n
cd jenkinscontroltest\r\ngit init\r\ngit remote add origin <remote code location>\r\necho \"Martin Berlove\" >> contributors.txt\r\ngit add -A\r\ngit commit -am 'Initial commit.'\r\ngit push -u origin master<\/pre>\n<\/blockquote>\n
![\"Setting](\"http:\/\/i.imgur.com\/kGckHUA.png\")
<\/a><\/p>\n![\"Setting](\"http:\/\/i.imgur.com\/agAw3VT.png\")
<\/a><\/p>\n\n
git status<\/pre>\n<\/blockquote>\n
\n
touch file1\r\ngit add -A\r\ngit commit -am \"Added a new file.\"\r\ngit push -u origin master<\/pre>\n<\/blockquote>\n
![\"Email](\"http:\/\/i.imgur.com\/qSwCim9.png\")
<\/a><\/p>\n![\"Build](\"http:\/\/i.imgur.com\/DMYgkKg.png\")
<\/a><\/p>\n![\"Overview](\"http:\/\/i.imgur.com\/dnS7EYb.png\")
<\/a><\/p>\n<\/h3>\n
<\/h3>\n
Project 2: TODO Comment Monitor<\/h3>\n
![\"Setting](\"http:\/\/i.imgur.com\/UdGufN4.png\")
<\/a><\/p>\n\n
cd \/var\/www\/html\/jenkinscontroltest\/\r\n echo \"TODO something to do\" >> file1\r\n git commit -am \"Added a comment.\"\r\n git push -u origin master<\/pre>\n<\/blockquote>\n
![\"Build](\"http:\/\/i.imgur.com\/5y9Vxxb.png\")
<\/a><\/p>\n