A Jenkins video tutorial to set up a build job

Transcript - A Jenkins video tutorial to set up a build job

Hello, and welcome to a beginner's tutorial to Jenkins for IT operations teams.

So to start off, think of Jenkins like a script orchestrator, it looks for an event, and then it will trigger a script and control the build environment that that script runs in -- so that'll make more sense in a minute, as we go along.

To start, let's go to Manage Jenkins and then scroll down to Manage Plugins. As a general rule of thumb, if you ever need Jenkins to integrate or work with anything, there's a plugin for that.

And let's go here to the available plugins. I have one specifically in mind, but it's worth looking through these to see what it can actually work with. For this demo, I'm going to install the file system trigger plugin, which will allow Jenkins to watch a folder for changes and then start a job or a project based on those changes.

So let's go ahead and install that now. All right; now that that's installed, we can go back to our Jenkins main page. You see I've already got a job here -- and we will get to that in a minute. But let's go to New Items so we can create our own project. Each of these is a different kind of project that Jenkins can create, but the 101 course we're going to stick with a Freestyle project, which gives us the most flexibility. And we're going to call this job the Filesystem Watcher. And I'll go ahead and click OK. Great.

Now we're in the configuration for our Filesystem Watcher job. It's worth noting that every Jenkins job is going to have about five sections that you want to look at. It sounds a little intimidating, but they're not as complicated as that. The first is this job parameters here -- job properties -- and this is:

• Do we want to pass parameters to this job?
• Do we want to call it something different?
• Do we want to use a custom workspace or custom build directory?

These are things that are specific to this job.

The next section here is Source Code Management. So this is going to be less of a concern for traditional operations teams. But, if you wanted to -- for developers or even for more of a DevOps-style setup -- if you have any configuration in code or any code in source control, you can hook up the source control here like GitHub or Accurev or something like that. It will link to that repository and pull it for changes.

The next section here: Build Triggers. This is what is going to start the job. And you see we have a few different options here. Some important ones to know: Trigger builds remotely -- will allow it to be called with a REST HTTP call. Next is build periodically -- so you can run a schedule and build it every so often. You can also pull SCM. So, as I mentioned earlier, we can hook up source code management, and we can hold that for changes, detect any changes and then run the job based on if changes were detected.

Finally, we have this FSTrigger down here, which is actually what I installed with my plugin; it wasn't available to us before. And I'm going to set this up to monitor a folder.

So a little background here: I have a folder on my C drive called Tools. And I keep a few utilities here that I like to have around to work with. And I want to make sure that folder is backed up. So let's go into Advanced -- now that we've told it what path to look for -- and you see, we can actually filter what things we want this job to look at. So, for example, if I was planning this at a configuration folder, and I only wanted it to watch for changes to an XML or JSON or YAML file, I could use a filter here that would point to those.

Next, I need to tell it how often to check that folder. Jenkins uses a cron timer, which is a pretty standard thing, but if you've never worked with them before, by clicking the question mark here, it will actually give you a bit of an explanation as to cron timers, and how to set one up. I want it to run as often as possible, so I will put in five stars -- which, as soon as we click off of this window, we will see when it will run. And if I go ahead and replace one of these with something else, we see the changes that would make. I am perfectly fine with it running as often as possible. And I'll go ahead and click off of this question mark so we can continue with the demo.

The next section here is Build Environment. Build Environment is if you want to inject anything into the build itself before it starts. This could be secrets or environment variables or additional parameters or anything else you might want to do. I always like to add timestamps to the console output so I can track what's going on a little bit better. Right.

And next we have our Build step. Build step is going to be invoking some kind of script. And again, you can find plugins that will allow you to do other things, but for the most part, it is a script that needs to be run. We'll go ahead and add a PowerShell command here. And you see, also, Jenkins has some environment variables that will be available in the Jenkins job itself. We're not going to dive into those today, but it's worth checking out.

You also have your standard environment variables ready, such as path or user home. Now if you have a more complex build, you can add more than one build step as well. Let's go ahead and add a batch command here, in addition to our PowerShell command. Some of these do have advanced tabs -- it's worth checking those out. They do often hide a bunch of needed functionality behind those, so definitely check those out.

Now, after our build step -- after our build is complete -- it gives us an option for Post-build Actions. Let's go ahead and see what's there. This would be something like sending an email, or starting another project, or putting an archive into an artifact, or something like that. I'm going to end up building the other project I have here, which is 'Backup Tools Folder,' which we will go into in just a minute. But it's worth noting that this is where you do things like send an email or update a database or monitor something like that.

I had a project once where I had a PowerShell script that would go and check something on a server once a day and then put values into an HTML report, and it would email a report to management about the status of that server and jobs that are run once a day -- all run through Jenkins. Let's go ahead and save that.

For some reason, it doesn't show it right away when you add a downstream job. But if we refresh the page we'll see that now our Filesystem Watcher job has a downstream project of the Backup Tools Folder job. And what that means is that when this finishes running, it's going to start this job. So let's go ahead and take a look here. You see I've tested this a few times. But if we scroll down to the bottom, this is just a PowerShell copy item from my C tools directory to my D backup drive directory. And let's go ahead and take a look at those for a second.

Okay, so we have C tools and D backup. As you can see there's some tools here under Tools and Backup is empty. So let's go back to Jenkins and we can continue our demo. Okay, so now it's time to test it out. I'm in my Filesystem Watcher project. And -- off screen -- what I'm going to do is I'm going to copy a new file into that tools folder. And we should see this build automatically in just a moment.

There we go, our job is done.

Now we can go and click on this number one job here, we see it was triggered by FSTrigger the change to a folder. If we go into the log here, we can see a few more details on that. We go back to the job information page here and then go to console output: You can also see it was the full log of the job. Jenkins will take whatever you enter in a script console, and then run it as a temporary script of that type.

So, if you look on the fourth line, for example, it's taken PowerShell.exe and running something from C, Windows 10, Jenkins, that looks like a randomly generated Jenkins script, PS one. And that's just taking the contents from that script window we entered earlier, making a temporary PowerShell file and then running it. And you'll see a couple lines later -- or excuse me, the next line -- that's our right host that we had. So the output of that script was successful. And the line below that is the same thing with batch and you'll see we have batch and PowerShell there.

Okay, and at the bottom here, it says it triggered a new build of the backup tools folder. You'll see we do have a build #13. Now whereas before it was only build number 12. Let's go ahead and go into that one as well. And we see it was started by the upstream project Filesystem Watcher. And again, if we go down to console output will see the right hosts that I had in there, but did it actually copy?

Let's go back to the file system and find out. Okay, we are back in our file system here and you'll see the file I added was a terminal.gif.

And if we go on our right side here into D backup, we have a new tools folder, and it mimics what is in the C tools folder.

All right, that's it for today. Thank you for watching.