Getting Started with Jenkins Automation

Welcome to my video on everything you need to know to get started with Jenkins. This is going to be one of the most comprehensive guides for Jenkins on YouTube. It contains both theory and practical labs that you can follow along with. Jenkins is a hugely sought over skill to have for DevOps, with engineers earning anywhere between $150,000 to $250,000 per year. Hopefully that's enough to motivate you to take the time to learn Jenkins, but if you need another reason, it's actually a really cool skill to have as it can be used to automate anything. In this video we're going to go over what you need to know to get a Jenkins server up and running, set up and manage Jenkins agents, as well as create a declarative Jenkins pipeline using the Groovy language. As always this video includes chapters and everything you see me do in this video is available on my github in the description below so make sure to make use of that as you follow along. So when getting started with Jenkins there's plenty of documentation on the Jenkins website. but who wants to spend their day reading documentation off of a vendor website? That's why I'm going to give you the too long didn't read version. Jenkins is an automation platform that allows you to build, test, and deploy software using pipelines. But it's not just limited to creating pipelines for code, it can be used to automate any task. I commonly use it to run my bash and python scripts as well as ansible playbooks. Jenkins provides a web GUI where you can create jobs and customize all the functionality that you want. such as source control management, pre and post build actions, as well as build triggers. This allows you to run tasks on demand by clicking a button or have them triggered automatically via webhooks. So now that you know what Jenkins is, let's get into Jenkins infrastructure, which is pretty simple. First you have the master server, which controls the pipelines and schedules builds to agents. And then you have the agents, which run the build in their workspace. So an example workflow may look like this. A developer commits some code to a git repository. The Jenkins master becomes aware of this commit and triggers the appropriate pipeline and distributes the build to one of the agents to run. It selects the appropriate agent based on labels which is something that you can configure through the Jenkins UI. The agent then runs the build which is usually just a bunch of Linux commands to build, test, and distribute your code. Now one thing you should know when getting into Jenkins agents, there are two main categories of Jenkins agents. The first is the permanent node agents. You can think of these just as standalone Linux or Windows servers that are configured to run Jenkins jobs. And these are just basic everyday servers. The only real setup of them is you need to have Java installed and you need to make sure that SSH is set up. as the master server usually makes connections over SSH. You'll also want to make sure that you have any type of build tools that you want to use on these servers installed as the agents are going to be the workhorses that run your actual builds. So those are permanent agents but there's another type of agent known as cloud agents which are a much more popular choice in real world environments. Some examples of cloud agents are Docker, Kubernetes, and AWS fleet manager. In these scenarios Jenkins can dynamically spin up agents based on the agent templates you configure. In the lab portion of this video I'm going to show you how you can set up Docker to be a cloud agent so whenever Jenkins jobs are run they are run in a dynamically provisioned Docker container. This is going to be very similar to how you would set up Kubernetes agent as well as EC2 fleet manager agent to dynamically spin up pods or dynamically spin up EC2 instances. Now we're almost ready to get started and set up our own Jenkins infrastructure but let's first talk about the two main build jobs that you're gonna run into with Jenkins. These are the Freestyle Build Projects and Pipelines. First is the Freestyle Build Projects which is the simplest way to get started with Jenkins and the way that I suggest you start out to learn Jenkins. Basically, just think of them as shell scripts that will be run on a server that can be triggered by specific events, like a developer making a commit to a GitHub repository. Freestyle projects are easy because you can use the UI and plugins to manage just about anything in the build. Most freestyle projects will be set up to execute a shell script, so as long as you are familiar with shell scripting or the Linux command line, you should be good. The next style is pipelines. Pipelines use Jenkins files written in the GroovySan text to specify what happens during the build. Pipelines are commonly broken into different stages. As you can see, this pipeline is broken into five different stages. The clone, build, test, package, and deploy stages. These stages can differ depending on the project, but this is a common workflow that I usually see. The clone stage is usually made up of pulling down the code from a git repository and setting up the local environment on the agent. The build stage takes the code and builds it, which usually means generating some type of local artifact on the code like a jar file, executable, or container image. The test stage, yes you guessed it, runs tests against the newly built code, and in the package stage, it gets packaged up so it's ready for deployment. And the deploy stage is when I usually send out artifacts to my registry. So a good example would be sending out a newly built Docker image to Docker Hub. So that's what Jenkins does. It's basically just a way to automate the work that developers don't want to do so they can save their time and do more productive things. So that's it for the theory portion of this video because like Morpheus says, no one can truly be told what Jenkins is. You have to see it for yourself. So let's go ahead and have a look at Jenkins. All right, so we are here on the Jenkins website with the installation instructions for Jenkins. There's a couple different options that they give you here. You can either install it directly onto the OS or you can run Jenkins in a container environment such as Docker or Kubernetes. The suggested method is to use Docker, so that's what we'll be doing. There's instructions on the Jenkins website how to do that, but I have a more summarized version of those instructions in my GitHub in the description below, so make sure to check that out if you want to follow along. I'm going to pull that up right now, and you can see that there's three major steps for the installation. The first step is to build the Docker image. The next one is to create a network called Jenkins and then to launch the container. I have commands for macOS, Linux and Windows so you can use either one. So let's go ahead and do this. The first command is going to build the Docker container using the Docker file that I have here and just to check it out you can see it's just like any other Docker file. This one's pulling from the Jenkins repository. And you can see it's also installing Blue Ocean. Blue Ocean is a popular add-on for Jenkins. It makes your CI CD pipelines look a lot nicer and just a little bit easier to manage and troubleshoot. We'll be having a look at Blue Ocean later on in this tutorial. So let's go ahead and pull up a prompt here and I'm going to start off by cloning my repository here. And once I've cloned it I'm going to hop into that directory so I can create the docker image. and I'm going to do that with my docker build command and you can see that it's building the container and it should just take a few minutes for you depending on the speed of your internet connection it's just going out and grabbing the docker image of Jenkins and then running apt update install and installing a couple plugins so once that's done I'm going to clear the screen to make this a little easier to see The next thing I'm going to do is docker network create Jenkins and you can see I'm getting an error that the network already exists. I already created this network But you should be able to see it and the way to verify that is just through a docker network LS command and you can see I have this Jenkins network already created so I can move on to the last step which is actually running the container command. And again, this is in my GitHub below. I'm going to copy that over from my other screen and paste it in here. And this is just going to start the container. And you can see exactly what it's actually specifying here. You can see that specifying the network of Jenkins. There's a couple environment variables here specifying the location of the certificates, the TLS version. and a couple map volumes and which ports should be published. So let's go ahead and do a docker ps and you can see that the docker container is now running and it's listening on port 8080. So let's go ahead pull up a browser and see if we can get to this website. Alright so I have it pulled up here And you can see that it's on this unlock Jenkins command. This should be the first thing that you see when starting a new Jenkins instance. And basically what it's telling you is you need to put in the administrator password. And that password is going to be at this location when you first install Jenkins. Now since we're running this on a Docker container, we're going to have to use the docker exec command to cat out this file. So I have that command saved in my GitHub. so let's go ahead copy it paste it into the terminal here and it spits out my password so I'll grab that put it in and we're in. Now we're at a screen where we can install Jenkins. I'm going to install with the suggested plugins. And this should go pretty quickly. It's just grabbing the most popular plugins that Jenkins uses, such as Ant and Gradle. A couple other things here. Let's just wait for this to finish. And then we're going to set up our user account. All right. So we're at create your first administrator. Go ahead and put in your details. I'm going to put in my details now and then hit save and continue. All right. For this instance configuration, you can just leave at. default and hit save and finish and start using Jenkins. Alright so this is the Jenkins UI in all its glory. I know it's not a lot to look at but it does get the job done. Let me zoom in a little bit here to make things a little larger and easier to see and let's go over what these items do. The first item here is your breadcrumbs so it'll make it easy to navigate through Jenkins and go down levels. something we're going to be using a lot when we're administrating our jobs. The next thing is New Item. This is where you create your projects and pipelines. We're going to be going into it shortly. The next thing is People. This is where you administrate user accounts. Build History gives you a history of all your jobs that have been run. Manage Jenkins has all your management stuff. This is where you set up agents. This is where you install plugins. We're going to go in here as well and I'll show you the most popular menus that you'd be using as a Jenkins administrator. The My Views and New View is just a way to organize your jobs and have things display nicely. Blue Ocean is a popular plugin for Jenkins that enhances your CICD pipelines. Once we have our pipeline created, we'll go into Blue Ocean and check out how it looks in Blue Ocean versus the regular Jenkins UI. For now, let's go into Manage Jenkins. And you can see that this brings up quite a few different options. Basically, these are all your options for managing Jenkins. So at the very top, you can see there's some notifications here. Let's go over them. The first one is just saying that building on the built-in node can be a security risk. This is just letting us know that we don't have any agents set up. So if we were to make a Jenkins pipeline, it would be running on the Jenkins master, which is not recommended. We're going to be setting up some agents so this is something that we can ignore for now. The next one here is it's just a warning about one of our plugins. Basically wants us to go in and update our plugin so we'll just ignore that one for now and when we get to the plugin section we'll go ahead and fix this. Let's go over the main items that you'd be using as a Jenkins administrator. So I'll scroll down here and get everything in the view. Alright, so let's see if we can speed run through the most popular items here. The first most popular one is Configure System. This is going to give you a lot of information about your Jenkins server and let you set some global parameters in regards to your Jenkins server. So you'll probably spend a little bit of time in here. The next popular one is Manage Plugins. As a Jenkins administrator, you're going to be spending a lot of time in here because Jenkins is a beast when it comes to plugins. And over time, companies install plugins, developers install plugins, and different plugins break each other. When you upgrade Jenkins, plugins break. So being a Jenkins administrator, you're going to be dealing with plugins a lot. So we're going to be spending quite a bit of time in here in this lab, and I'll show you how to administrate plugins. The next one is manage nodes and clouds. This is where you're going to go ahead and set up your agents as well as clouds like... Kubernetes, Docker, AWS, anything to do with agents will be in here. The next section is the security section. A lot of these are pretty obvious. You can configure global security settings, you can manage users, and then you have managed credentials. The managed credentials is probably the least obvious one in this list. This is where you would store SSH keys or API tokens. Now you don't have to use Jenkins as your credential manager. You could use something like AWS secrets if you want, but Jenkins does have a built-in credential manager. So go ahead and use that if you would like. Down below we have some other pretty obvious things. You can get some system information about Jenkins. There's some logs, some load statistics. I don't spend a lot of time here. At the bottom here you have a couple tools, mostly for troubleshooting Jenkins, but one that you may run into that you need to use is prepare for shutdown. So you would use this in a situation where you need to take the Jenkins server offline to perform some sort of maintenance. You wouldn't want to just go ahead and reboot the Jenkins server or just shut it down because you would be interrupting current jobs that are running. So what you would want to do is set it to prepare for shutdown. And what that'll do is make it so Jenkins doesn't start any new jobs, it just finishes the jobs that are currently running. Alright, so now that we know the main management features of Jenkins, we're ready to create our first project. So let's go up to Dashboard, and then New Item. And in here you can see there's quite a few different options, but the ones that you're going to be sticking with mostly is Freestyle Project and Pipelines. Pipelines are the more advanced style where you use the Groovy script. We're going to be getting into that later on in the video, but freestyle projects are also pretty popular and they're a great way to start learning Jenkins. And if you're administrating Jenkins servers on the job, doing any type of consulting, you're going to run into freestyle projects, so it's going to be something you want to learn. So let's go ahead and create one. We'll have to give it a name. So Now the first thing I can say here is do not create a name that has spaces in it. And the reason for this is because in the back end Jenkins is actually going to be creating a folder based on this job. And it's going to be something that we have a look at so you understand the file structure of a Jenkins server. But for now just make sure not to use spaces and use something like underscores or dashes instead. So I'm going to call it my first job. Make sure Freestyle Project is selected and hit OK. Alright, so we are in the project settings of our first build that we're creating here. Let me take you through the category of settings that you're going to run into here. The first one is just a couple build options at the top. You can ignore those for now. It's going to be something that you get into as you get more advanced into Jenkins. The next one is Source Control Management. So you're almost always going to be using something like Git. And then you just put in your repository URL. Jenkins is going to go ahead and pull that repository down into your workspace and use that code. The next one is your build triggers. So your build triggers is what is triggering your job. So popular options here is to have GitHub send a webhook to your Jenkins server. Now this can be a little more difficult. If your Jenkins server is behind a firewall, you'll need to either open ports or use some sort of proxy service to make sure that webhook gets to your Jenkins server. Another way to sort of cheat the system is to use this polling SCM. And what this is going to do is it's going to have Jenkins reach out to GitHub and just check periodically. So that's one way to get around if your Jenkins is behind a firewall and cannot receive webhooks. Another option is to just build periodically and this is just the same thing as setting up a cron job. You just set a schedule and your Jenkins build will run based on that schedule. For build environments, a popular option is to delete the workspace before the build starts. This just makes sure that you have a clean environment before your build runs and it deletes any artifacts that have been left over by Jenkins that were created during the last run of the job. And then scrolling down, we have the build. These are your build steps that your build is going to go through. And then we have our post build actions. And these are just things that are going to happen when your build is complete. So some popular options here might be to send an email notification. And if you had the Slack plugin, you could send notifications to Slack. So let's go over to build. And the most popular one that you're going to use is just to execute a shell. So this is just like bash scripting. So whatever we run here, the Jenkins server is going to run within its workspace. So the simplest thing that we could do here is just echo hello world, hit save and then build now. And this is going to run our job. And we got an error here, so let's go check that out. And it failed because I opened that git repository thing. So let's go back to our project. Go to configure. And I left this empty. Let's just go ahead and set it to none. And that should fix the error that we have there. So let's go ahead and save it. Hit build now. And now we can see that the job has run successfully. So we can click into it. And there we go. It echoes hello world. So that's your simple hello world Jenkins build. Let's go back into the build. Just go up to back to my project and then configure and we're going to do something a little more complicated than just echo hello world. Let's get into the available environment variables. So if you click here, just open it in a new tab, you can see all the environment variables that are set for Jenkins that you can use throughout your build and you're going to be using these variables quite a bit whenever you're creating jobs the most popular one that i like to use is build underscore id and this gives you the current build id i always use this when i'm versioning my docker images that i spit out from my build i like to specify the build id and then that way i know which build actually built the image so that's a popular one that i like to use Another popular one is the build URL. So you can see it here and you can see it gives the URL for the build. So that's a good one. So let's go ahead and put these into our job. So to use the Jenkins variable I usually just go echo and we can see the build id of this Job is dollar sign and then I usually throw it into these two curly brackets and then I go build Underscore ID and then because we can we'll go the build URL is and then we'll put the build URL go ahead and save it and then build now and then we can go into our job and depending where you click the icon in jenkins it's either going to bring you to this screen or bring you right into the logs so let's go into console output and there you can see that it is saying hello world because we have that at the start of our job and then the build id is three and then the build URL is here. Now one thing that you may notice is it's spitting out everything twice. To explain that this is the actual command it's running with this plus sign and then the next line is just the standard out of the console. So since we're echoing hello world that's sending standard out so that's the standard out. So that's why you're seeing everything twice in this job. Looking at this build URL So that basically just brings us here. So this is a really good one if you're sending Slack notifications. You can send the build URL to one of your developers, letting them know that the build is done, and then they can click it and see everything that happened. So if you click it, you see it brings us here, gives us all the information about the build. Okay, so let's go back to our project and go to configure. So the next thing that I want to do here is just show off the workspace. So if we go ls, this is just going to send the ls command to Linux. I'm actually going to go lsltr, and this should show all the files within the current workspace. Now since we don't have any files this probably won't output anything. So let's create a file and we'll go echo 1 2 3 4. And then we will send the output to a file called test.txt and let's do an ls after that. We'll hit save, hit build now, and job number four is done. By the way, you can see there's two different links here. This one brings you to the main build page. This one brings you directly to the console output so I always hit the check marks or the x's. So let's hit this. You can see that it ran the LSLTR first, there was zero files, and then you can see that it echoes 1234 out to the file, and now we have that test.txt. Now if we go back to our project, you can see we have this workspace option, and if we go into workspace, you can see that that test.txt file exists. And there you go, click it. you can see 123. Now just for science let's go ahead and run the build again. And it's now done and if we go there this time you can see on the first LSLTR that the file already exists. So basically what this means is we are not clearing out our workspace and the files from the previous build are already in our directory. So if we go back to our project We can change that by going delete workspace before build starts. And you can see here that you can add patterns to delete specific files. I'm just going to delete everything so we'll just leave the defaults. Hit save, hit build now. The job is complete. Go in there. Now you can see the first ls shows that there's zero files. Then we create the new file. Perfect. Now another thing that I would like to show you before we get into more advanced builds is the actual file system of Jenkins. So to do that let's hop into the terminal and I'm gonna run a command here to get into the actual docker container so it's just docker exec dash IT the docker container name and then bash this will give us a bash shell into the container And now we're on the actual Jenkins master. We're just in the root folder. So we'll want to go into the Jenkins folder. And we actually specified it in our docker run command here. So it's this volume that we mounted. So var slash Jenkins home. So we'll go in here and do an LSLTRA. Quite a bit of files and directories here. The one that we're interested in is workspace. So let me clear the screen and then go into workspace. And now if I do an LSLTRA, you can see that we have a folder here called my underscore first underscore job. So this is the job that we created. So whenever you create a build, it's going to have its own workspace under a folder of the job name. That's why you don't want to create spaces. And you can actually go in here and you will see all the files in here. So we can see our test.txt and cat it out and there you go. One, two, three, four. So actually SSHing into the Jenkins machine or doing a Docker exec into the container and having a look at the file system is something you're going to do. quite a bit with Jenkins, especially when you're troubleshooting builds and jobs. Sometimes it's a lot easier to actually just go into the file system of the Jenkins server and have a look there. So a really great troubleshooting tool. Let's actually go back to the Jenkins home folder. So we can actually just go cd tilde sign and that should bring us here. If you do pwd you can see we're in the Jenkins home folder. And if we look at the files again, you can see that there's other folders in here. So there's actually quite a bit of troubleshooting you could do within the file system. You can see that this plugins folder, this would be where you would have all your plugins, the updates folder where all the updates go. And then you can see there's a couple like XML files for the Jenkins configuration, as well as logs. So this is a good place to go to troubleshoot your Jenkins master if you need to. Now that we've seen the file system of Jenkins, let's hop back into the Jenkins console and I'm going to go back to the dashboard. And you can see that we have this job coming up here nicely. And you can see there's a couple things here. You can run the job. It tells you when it last successfully ran, when the last failure was, and the duration that it took the job to run. Now if we were to create some new jobs, they would show up here as well. So let's go ahead and do that. I'm going to go new item. And what we're going to do for this one is we're going to clone down our report. repository and run a Python script. So we'll call this one my Python job, hit OK, and I'm going to go to this source control management, click get, and put in my GitHub repository. So you should do the same if you're following along. There's a Python script in this repository that we're going to run, and you can see there's credentials here. Now this is a public repository so we don't need any credentials for cloning it down but if this was a private repository you would need to select your credentials or go ahead and add them. So if you're using a private repository go ahead and make sure you're using credentials for that. But for us we're okay so let's head down to the bottom and we're going to execute a shell and What we want to do here is I just want to see which version of Python is running. And actually one quick troubleshooting step I want to run is let's just see if Python is installed. Hit Python on the Jenkins server and you can see that command not found. So let's try just Python3. And we can see that Python 3 is installed. So let's go ahead and go to our job and make sure we use Python 3. And then we want to run our script called hello world dot pi. And I believe that's what it's called in our repository. Yes, hello world dot pi. So let's go ahead and run that one. Go ahead and save it and hit build and check out the job. And there we go. We can see everything that it did. So you can see that it went out to my GitHub repository. It cloned everything down and then it ran Python three. Hello world. And we got the output of our script. So something as simple as this is actually quite powerful. Instead of us having to log onto a server to run a Python script, and you know make sure we have SSH to the server to make sure we can run the script. We can just create a Jenkins job, hit a button and we'll know that it runs. We can also set up triggers for this job to be triggered like webhooks or when a repository is updated as well as sort of like a cron schedule and we'll also always get a history of when that script was run. as well as full log output. So this is just something that you can tie your Python scripts to and then just sort of keep track of whenever they're run. I also love doing this with Ansible and running Ansible playbooks instead of logging onto like a server and having someone run the Ansible playbook. I just set up a Jenkins job to run the playbook and then you have a full history of whenever that playbook was run. and if it was successful or not. All right, so now that we have the basics of creating builds with Jenkins, let's get into more advanced topics like setting up agents and then building pipelines using the Groovy Santax. So I'm going to go back to the dashboard and then manage Jenkins and then manage nodes and clouds. And then on the left-hand side, there's two main options. There's the new node and configure clouds. So if you go to new node this is how you configure a permanent agent. Basically this would just be any sort of like Linux or Windows server that you have that is sort of always available. You set it up as a permanent agent and Jenkins just connects to it via SSH and then distributes the jobs to it. Now in my opinion this is sort of the older more deprecated ways of creating agents. Wait people are usually doing now is configuring clouds. So if you go to configure clouds, this is how you set up agents using cloud platforms such as Docker, Kubernetes, AWS. So now that we're in here we can see that there are no current cloud implementations available to us right now unless we go to the plugin manager. And that just leads us to the plugin manager. So we'll go there. And you can see that it's filtering on cloud providers here and this is basically just a list of all the cloud providers that you can use for your agents. Let's go ahead and install Docker, but if you're interested in Kubernetes or using AWS you could use those. So I'm just going to do Docker and I'll say download now and install after restart. And then it's going to go through everything. These look like just the first plugins that I installed during the setup. Down at the bottom here you can see Docker and it'll be activated during next boot. So I'm going to go ahead and click this which will restart the Jenkins server. All right once the Jenkins server has restarted you should be asked to sign in again. So you can just sign in and then you'll want to go over to manage Jenkins. and we should be able to go to our plugin manager and see that Docker is installed. If we go over to the installed tab here, we can see that everything to do with Docker has been installed. And if we go back to dashboard, manage Jenkins, manage nodes and clouds, then configure clouds, we can see that we have adding Docker as an option. So we'll go ahead and add Docker and I'm going to hit Docker Cloud Details here. And there's a couple things that you need to do to set up Docker. The first thing is you need to set the URI of the host that is running Docker. So if you wanted to run Docker within the Jenkins you could just use like and then the port for Docker. But if you want to run it remotely then you would put in the IP address of the remote server. Now I'm running Docker Desktop on my local PC here, so I don't want the Docker to run within the Jenkins master, I want it to run within my actual PC that's running Docker Desktop. So there's a couple things that we need to do here, and there's actually a really good Stack Overflow article that outlines how to do this. I'll put it in the description below. And I also have details in my GitHub how to do it, and you can just follow along here on how to do it. So what I first want to do is launch a container running the Alpine SOCAD image. So I'm going to copy this command over from my GitHub and put it in. And this should start up a container that's going to help proxy the connection from our Jenkins master container over to our local host here. So you can see that the container is up. I'm going to grab this container name and I'm going to do a docker inspect on it. And what I'm interested in here is the IP address of the SOCAT container. And it's right here the So I want to forward my connections for docker to this IP address. So let's go in here and we'll go TCP, throw in that IP address, and then it's going to be port 2375. And then I'm going to hit enabled and test connection just to make sure that everything goes through OK. And you can see that it has connected properly. Now, if I... put something incorrectly here like the wrong IP address you're probably going to get a connection error like the one that's popping up here and you'll just have to take whatever comes up here and go show details and troubleshoot it. Go to Google check to see what people suggest but most likely it has something to do with routing. Now let's go ahead and change this back to three and then just have it test and then go ahead and hit save and that'll bring us back here. Let's go back to manage nodes and clouds, back to configure clouds and we now have our docker cloud details set up. But now what we want to do is create a docker agent template. So I'm going to hit this here and then hit add docker template and there's a few things that you need to set up here. The first one is the label and what labels are used for is for the master to use to determine which agent should run the build. So it should be something descriptive about the agent I'm just going to call it docker-agent-alpine and then I'm going to say that this should be enabled. Make sure that you do the same if you're following along and then I'm going to take this label and just give it the same name. as the agent template. And then this is the important part. This is the actual Docker image that you're going to be using. I'm going to be pulling one from Docker Hub, and it's going to be a Jenkins agent image running Alpine with JDK 11. Now, if you want to use your own image, you can point to it on Docker Hub, or you can set up a private repository. You'll just need to make sure that you put in your credentials. So the Jenkins master can authenticate it to it and pull down the Docker image. Now for some container settings, we can leave that as default. Instance capacity, this is basically how many agents it's going to actually spawn. So you're going to want to set this to a number. I'm going to keep it really low for now, just because if you run into any issues, you might be spawning lots of agents and you don't really want to overwhelm your system. Another really important field for us to fill here is the remote file system root. This is basically where your workspace folder is going to get created. This is your Jenkins home folder. So I'm going to call it slash home slash Jenkins, as this is the default that you should be using for all your Jenkins agents. Now if we scroll down, I believe that's everything that we need to set here. Let's go ahead and hit save. And let's go back to our dashboard and let's go to my first job, configure. And what we'll want to do here is select this restrict where this project can be run. And then we're going to say Docker agent Alpine. We can just select this one. I'm getting a notification that this doesn't exist. This label doesn't exist, but sometimes it's just Jenkins causing trouble. You can see that the autocomplete had a space in it so when I remove the space that seemed to fix it. Also sometimes if you go in and out of the job that will fix it as well. So go ahead and hit save and now when we build it should run the build on our docker agent. So I'll go build now. And you can see that it's looking for an agent that has the label Docker Agent Alpine. Looks like it's still looking for it. So let's go ahead and troubleshoot this. Make sure that this is the right label. I'm gonna open up another tab here and just go to configure. Go to a dashboard actually. then manage Jenkins nodes configure clouds take a look at our agent template we can see that's the correct name here and it looks like it's enabled so it should be good and if we go back back to here go to cloud details let's go ahead and test the connection the connections working good So everything here should be working fine. Let's go back into the job. And it looks like I was just being a little bit impatient as I was recording here. The agent picked it up and ran the job. If we run in here, we can see it was building on the Docker remotely on this agent that it created. And the job completed successfully. And we can also go here, built on Docker, and then it tells you everything in regards to Docker. Now let's go ahead and have a look at our other job that we created. And you can see it's this Python job. So what would happen if we went in here and restricted it to our Alpine image? Let's go ahead, and I think that'll fix itself. If we just hit build now, we'll give it a minute to build, go back into configure, and I guess I just didn't read it correctly. It's saying that it does match it, so let's go back and you can see that it did not run successfully. So let's have a look at why. And you can see that it checked out the code, but it couldn't run the Python command because Python 3 isn't available. So the reason for this is because that agent template that we created is just pulling down a Jenkins image from Docker Hub that doesn't have Python installed. So what you would probably want to do is create your own image and that's exactly what I did and I have one available on Docker Hub that you guys can use as well. So let's go back to configure clouds. under Manage Jenkins and we're going to set up a second agent and give it a new label. And then this second agent is going to run all our Python builds. So let's go to Docker Agent Templates. We have our first template here. I'm going to take the first part of this label and then scroll to the bottom. and go add Docker template and then I'm going to give it a similar label but instead of saying Alpine I'm going to say Python. Make sure it's enabled, give it the same name as my label and then for the Docker image I'm going to use my Docker image that I created from Docker Hub. So it's just devopsjourney1 myjenkinsagents colon python1 And this is what the Docker file looks like if you're interested. Now I'm just going to complete the other settings here. So instance capacity of two and then home slash Jenkins for the remote file system. That should be enough to get us started. So I'll go ahead and hit save. And then let's go to our dashboard, go into our Python job, configure it. And instead of using just our. Alpine Docker image we're going to use our the label of Docker agent Python which has our Python image so we'll save that and we will run it and there you go if you're patient enough to watch you can see that it's selected the agent let's just go ahead and see and there we go the Python script ran successfully on our docker agent that had python installed on it. And there's actually a bug in my script that I didn't notice but maybe some of you guys did. When you run python hello world it's saying hell world instead of hello world. So let's go ahead and fix that. And one thing that we can add into our build is to have them triggered automatically. So I'm going to go here and I'm going to configure And in our build triggers, I'm going to say pull the SCM. Pull SCM is a way to have your Jenkins master monitor the GitHub repositories and just check for any changes. It's more simple than setting up webhooks, especially if your Jenkins master is behind a firewall. So that's the method we're going to take here. And I'm going to paste in a schedule here. So it's star slash five star star star star. So this is very similar to setting up a cron job. What this star slash five means, it's going to do it randomly every five minutes. And this is a best practice with Jenkins because you don't want all your Jenkins jobs going out once per minute all at the same time. This just helps the Jenkins master distribute when the jobs go out and look at their GitHub repositories. So we're going to keep it as is there. Go ahead and hit save. And then I'm going to go into my GitHub here and I'll have a look at this script and I can go ahead and easily fix this just in GitHub. Change it to hello world and go ahead and commit the change. And then I'm going to go here and just wait for the build to trigger. I have it running like. randomly once every five minutes so it should trigger here within the next five minutes. I'm just going to go ahead and speed up the video. Alright so the job has completed and you can see if we go in here you can see at the very top that it was started by an SCM change. So this build was triggered automatically when we did a commit on our repository so we didn't have to go in and press the build button it just went ahead and ran the script. So something that you can add to any of your repositories if you want the build to trigger when a change is made. Okay so so far in this course we've learned how to install and set up a Jenkins master as well as Jenkins agents. We've also been over how to set up a freestyle project and create basic builds. The next thing we're going to have a look at is setting up CI CD pipelines using the Groovy language. Now to get started with this all you have to do is go over to new item And then instead of going freestyle project you create a pipeline. So we'll call this my first build Pipeline and we'll go ahead and hit OK. OK, so this looks very similar to what we've seen before with the freestyle project. But if you scroll down, you'll notice that you don't have a lot of the options that you did before, and that's because they're all going to be built into this pipeline script, which we need to define down here. Now there's two main ways that you can get started with doing this. The first one is you can just create your pipeline script. directly into the Jenkins UI. Or the second option is to use what's called a Jenkins file and that's the preferred method. You just have a Jenkins file in your source repository and you point this pipeline over to that Jenkins file and it takes in your pipeline script there. We're gonna start off just using this pipeline script but then later on in this video we'll check it into our source control and have Jenkins, check it out from there and run the pipeline that way. Now to get started here, I'm going to head on over to my GitHub repository and in there I have this JenkinsFile.template. So I'm going to take this, copy it and put it in here. And this is a good basic template that you can start off with for all your projects. And if we just scroll to the top, you can see that it's got some nice syntax highlighting. This is in the Groovy syntax which follows a JSON format. And in case you are wondering, this is a declarative pipeline. This isn't the scripted format of a pipeline. This is the declarative. So if you're looking up syntax for this, make sure you're checking declarative pipelines. Those are the ones that you should be starting out with when getting started with Jenkins. But let's go through this pipeline. There's a couple of things that I want to break down. The first one mentioned before is everything is wrapped in this pipeline parameter. And then the first thing we do is we select the agent that we want this job to run on. So this is very similar to what we set up before to restrict which agent that the build runs on. And we're specifying it based on the label. So for our pipeline, we want to set this to the label of our agent. I believe that was docker agent dash python and now that we have our label selected the next set of code here is the stages and within the stages we have individual stages. So this is a three-stage pipeline first to build next to test and the last stage is to deliver. So this is good for a test build. Let's go through the steps. So you can see that for the stage build, each stage has steps and there's two steps within each stage. The first step is just doing a basic echo from the Jenkins agent. And then the next step is to just run a shells command. And this is just a placeholder to also echo here. But we're going to be adding in our Linux commands to actually do stuff here. So I hope that makes sense. It's going to make sense as we start running these builds and improving on it. So let's go ahead and hit save and let's go ahead and build. And then if we go into the build here, let's actually go back here and you can see immediately that the pipeline looks a lot different than just regular builds. You can see here that it's separated into the three different stages that we have set. build, test, and deliver. And then you can see that the build is green, but test and deliver are red. So it looks like our build failed at the second stage of our pipeline here. Now you can go into the logs of each of these, and it'll tell you exactly what it was doing. So you can see the first thing it did was print the message building, and then it ran our shell script, which just echoes right now. Let's go into our... test one and it says testing and then the shell script fails and it looks like it's an unterminated quoted string so that should be easy enough to fix let's go into configure and build is good it was this one the test stage so we'll fix the quotation And our deliver stage looks okay. Now the reason that deliver failed even though it looked okay is because test was an upstream stage and basically if an upstream stage fails your downstream stages are going to fail as well. So let's go ahead and hit build and I'll stay on this page this time and here you can see that it's going through the stages and since our build is so quick it just immediately updated but if you're doing a longer build you would see sort of like a progress bar. All right so that's pretty good. Let's up our game by using a Jenkins file and just improving this pipeline. So I'm going to pull up my Visual Studio code here and I'm just going to take this, copy it, paste it, and then just rename it to Jenkins file. And I actually need to fix this quotation here because it was missing. And this should be good enough for our job. But I actually want to improve our job before I upload this to GitHub. And the improvement I want to make is to have Jenkins pull the SCM, which we did with our previous project. And basically this means that Jenkins will reach out to GitHub. And if there's any changes on the repository, it's going to go through the build. So... I just looked up this syntax by going through a Stack Overflow article and this is it looks like the one that we want and by the way this is how most of us DevOps engineers work it's just searching for what we want on Google and then finding the Stack Overflow article and putting it in DevOps is just like building Legos so anyways this should work I want it to pull Every five minutes actually, so I just manipulated the parameters So it will pull once every five minutes if there's new code on github It's gonna run the build so I'm gonna take this and I'm going to push it out to github here Just do my commit And then within my actual project I'll need to convert this. You can just get rid of that and instead of using PipelineScript we want to change this to PipelineScript from SCM. We'll say git. We'll snag this repository URL. If you're doing this on your own make sure to change this to your GitHub URL. And if it's a private repository, you're going to have to use credentials. Mine's public, so this will be fine. And then the script path, we just have it set as Jenkins file. But you can name the Jenkins file anything that you wanted and put it in any directory that you wanted. You just need to make sure that this was up to date. So this should be good. I'm going to go ahead and hit save. And I'm actually just going to trigger this one manually just to get it going. but for future builds next time we do like get commit and push to github this build should trigger automatically so let's just go ahead and make sure the build runs using the jenkins file i'm just going to hop right into the console output so it obtained the jenkins file from get so we're looking pretty good here And I actually forgot to update this, so this job is just going to run forever. Let's go ahead and change my template. Sorry, not my template, change the actual Jenkins file. And change this to Docker Jenkins, Docker Agent Python. Alright, I have the memory of a goldfish. Let's go ahead. These changes look good. I'm going to put it up here and just go Undated Jenkins file and I'm just gonna push this way. Double-check GitHub. Make sure our changes are there Alright, that looks good to me. And this should run. Let's just go ahead and cancel this build. And I'm actually just going to go grab a drink, wait five minutes, and see if my build automatically triggers. Alright, so I left it for about ten minutes here, and it didn't look like it automatically triggered. If we go into Configure... You can see that it picked up these poll SEM settings from the Jenkins file and It looks like it should have run I'm just gonna be impatient here and I'm gonna hit build now and In here my Jenkins file, I'm actually just gonna change this to star and then this way it'll just run once a minute and that's fine for our lab environment. Anyways let's go check on the build and see how it's going. It looks like it was successful. It ran on the docker agent Python and everything ran successfully and if you look up there it used the Jenkins file to do it. Now one thing you may notice is the output of this changed and that's because an additional stage was added. It actually added the checkout stage and the reason it did this is if you go into configure underneath the pipeline we're saying pipeline script from SCM. So when you do that it automatically adds the step to clone down this GitHub repository. So that's the reason for that. One thing that you'll notice here is it cleared out the history of the old jobs because the additional stage was added. But that's okay, it's just one of the little quirks of Jenkins. Let's go ahead and build out our pipeline more. So I'm going to go back into Visual Studio Code and right here we have our three stages, the build, test, and deliver. Let's actually flesh this out. So you can see in the repository I do have this application called my app and if we just look at it you can see it's a python file and as you can see this is a pretty simple script what it's doing here is it's first importing the fire library and then it's just creating a cli application that returns hello world now if we were to run this script on our Jenkins agent it would fail because it doesn't have the fire library So let's actually go to our Jenkins file and for build instead of echoing let's say cd into my app and then go pip install dash r requirements dot text. So now the Jenkins agent will make sure that it has the fire library installed and then for testing Let's go ahead and run our script. So we'll go python3 hello.py and there is actually two ways that I could do it. It should work if I just run the python application by itself, but it'll also accept a parameter. So let's run it both ways. So I'll go python3 Hello.py name equals brad and actually will need to be in the my app directory. So that's perfect. So the first thing it's going to do is install the requirements for this application. And the next thing it's going to do is run the application and make sure that it's running OK. So I'm going to save this and push it over to my repository. And let's go here. Oh, and it looks like it's already building our job here. It was automatically triggered through SCM. Checkout went good. Now it's going through the build. and test and deliver. Alright let's have a look at how these look. So console output you can see the cloning went through fine. The next thing it did was it did pip install requirements.txt so it installed the FHIR library and then it went into the testing stage and then it ran python hello hello world and then it ran it with a parameter brad hello brad and you can see both of them worked so let's go ahead and have a look at this in blue ocean and i'll just show you how the interface of blue ocean looks so much nicer than this sort of outdated jenkins pipeline so if you just go to open blue ocean You can see that the pipeline has all our different stages here. It started, build, test, deliver. And if you click on each individual stage, you can see exactly what happened in these stages. So you can see the checkout from version control, our echo message, and then what it actually did. And went into the MyApp, installed the requirements.txt. So Blue Ocean is pretty good for giving you a nice interface so you can go in and look at the build and have a look at what happened in each of the stages of the build. A lot of your job as a DevOps engineer is going to be troubleshooting these pipelines, so having a nice interface to do it is always good. And Blue Ocean just really cleans things up, as you can see. So that's basically all I want to show for Blue Ocean. If you followed along with this video then you should have it available to you as well to go in. And here's the main page of Blue Ocean. So we can see our actual pipeline here and if we look we can see oh it was started by me basically when I clicked the go button and then this one was automatically triggered and yeah you could run the build from here if you wanted you could disable the build and if you just go to configure it just brings you back to the old Jenkins. interface. So that's all I really wanted to show for Blue Ocean. It's a really cool thing to get into, especially when you get to the multi-branch pipelines. But for our purposes, it's just a nicer looking Jenkins interface that'll help you troubleshoot Jenkins jobs. So that was your intro to Jenkins. In this video, we went over the key skills such as installing and setting up a master server, setting up Docker Cloud agents. We also covered how to set up and manage freestyle projects. And lastly, we went over setting up pipelines using the declarative language Groovy. I hope you enjoyed this video course and found it gave you practical skills on how to use Jenkins. If you have any questions, leave a comment below. And if you haven't already, please check out my other videos and subscribe to the channel. Thanks again for watching and I hope to see you in the next video.

Jenkins is a hugely sought over skill to have for DevOps, with engineers earning anywhere between $150,000 to $250,000 per year. Hopefully that's enough to motivate you to take the time to learn Jenkins, but if you need another reason, it's actually a really cool skill to have as it can be used to automate anything. In this video we're going to go over what you need to know to get a Jenkins server up and running, set up and manage Jenkins agents, as well as create a declarative Jenkins pipeline using the Groovy language. As always this video includes chapters and everything you see me do in this video is available on my github in the description below so make sure to make use of that as you follow along.

So when getting started with Jenkins there's plenty of documentation on the Jenkins website. but who wants to spend their day reading documentation off of a vendor website? That's why I'm going to give you the too long didn't read version.

Jenkins is an automation platform that allows you to build, test, and deploy software using pipelines. But it's not just limited to creating pipelines for code, it can be used to automate any task. I commonly use it to run my bash and python scripts as well as ansible playbooks. Jenkins provides a web GUI where you can create jobs and customize all the functionality that you want.

such as source control management, pre and post build actions, as well as build triggers. This allows you to run tasks on demand by clicking a button or have them triggered automatically via webhooks. So now that you know what Jenkins is, let's get into Jenkins infrastructure, which is pretty simple. First you have the master server, which controls the pipelines and schedules builds to agents.

And then you have the agents, which run the build in their workspace. So an example workflow may look like this. A developer commits some code to a git repository. The Jenkins master becomes aware of this commit and triggers the appropriate pipeline and distributes the build to one of the agents to run. It selects the appropriate agent based on labels which is something that you can configure through the Jenkins UI.

The agent then runs the build which is usually just a bunch of Linux commands to build, test, and distribute your code. Now one thing you should know when getting into Jenkins agents, there are two main categories of Jenkins agents. The first is the permanent node agents. You can think of these just as standalone Linux or Windows servers that are configured to run Jenkins jobs.

And these are just basic everyday servers. The only real setup of them is you need to have Java installed and you need to make sure that SSH is set up. as the master server usually makes connections over SSH. You'll also want to make sure that you have any type of build tools that you want to use on these servers installed as the agents are going to be the workhorses that run your actual builds. So those are permanent agents but there's another type of agent known as cloud agents which are a much more popular choice in real world environments.

Some examples of cloud agents are Docker, Kubernetes, and AWS fleet manager. In these scenarios Jenkins can dynamically spin up agents based on the agent templates you configure. In the lab portion of this video I'm going to show you how you can set up Docker to be a cloud agent so whenever Jenkins jobs are run they are run in a dynamically provisioned Docker container.

This is going to be very similar to how you would set up Kubernetes agent as well as EC2 fleet manager agent to dynamically spin up pods or dynamically spin up EC2 instances. Now we're almost ready to get started and set up our own Jenkins infrastructure but let's first talk about the two main build jobs that you're gonna run into with Jenkins. These are the Freestyle Build Projects and Pipelines. First is the Freestyle Build Projects which is the simplest way to get started with Jenkins and the way that I suggest you start out to learn Jenkins. Basically, just think of them as shell scripts that will be run on a server that can be triggered by specific events, like a developer making a commit to a GitHub repository.

Freestyle projects are easy because you can use the UI and plugins to manage just about anything in the build. Most freestyle projects will be set up to execute a shell script, so as long as you are familiar with shell scripting or the Linux command line, you should be good. The next style is pipelines.

Pipelines use Jenkins files written in the GroovySan text to specify what happens during the build. Pipelines are commonly broken into different stages. As you can see, this pipeline is broken into five different stages.

The clone, build, test, package, and deploy stages. These stages can differ depending on the project, but this is a common workflow that I usually see. The clone stage is usually made up of pulling down the code from a git repository and setting up the local environment on the agent. The build stage takes the code and builds it, which usually means generating some type of local artifact on the code like a jar file, executable, or container image. The test stage, yes you guessed it, runs tests against the newly built code, and in the package stage, it gets packaged up so it's ready for deployment.

And the deploy stage is when I usually send out artifacts to my registry. So a good example would be sending out a newly built Docker image to Docker Hub. So that's what Jenkins does.

It's basically just a way to automate the work that developers don't want to do so they can save their time and do more productive things. So that's it for the theory portion of this video because like Morpheus says, no one can truly be told what Jenkins is. You have to see it for yourself.

So let's go ahead and have a look at Jenkins. All right, so we are here on the Jenkins website with the installation instructions for Jenkins. There's a couple different options that they give you here. You can either install it directly onto the OS or you can run Jenkins in a container environment such as Docker or Kubernetes. The suggested method is to use Docker, so that's what we'll be doing.

There's instructions on the Jenkins website how to do that, but I have a more summarized version of those instructions in my GitHub in the description below, so make sure to check that out if you want to follow along. I'm going to pull that up right now, and you can see that there's three major steps for the installation. The first step is to build the Docker image.

The next one is to create a network called Jenkins and then to launch the container. I have commands for macOS, Linux and Windows so you can use either one. So let's go ahead and do this.

The first command is going to build the Docker container using the Docker file that I have here and just to check it out you can see it's just like any other Docker file. This one's pulling from the Jenkins repository. And you can see it's also installing Blue Ocean.

Blue Ocean is a popular add-on for Jenkins. It makes your CI CD pipelines look a lot nicer and just a little bit easier to manage and troubleshoot. We'll be having a look at Blue Ocean later on in this tutorial.

So let's go ahead and pull up a prompt here and I'm going to start off by cloning my repository here. And once I've cloned it I'm going to hop into that directory so I can create the docker image. and I'm going to do that with my docker build command and you can see that it's building the container and it should just take a few minutes for you depending on the speed of your internet connection it's just going out and grabbing the docker image of Jenkins and then running apt update install and installing a couple plugins so once that's done I'm going to clear the screen to make this a little easier to see The next thing I'm going to do is docker network create Jenkins and you can see I'm getting an error that the network already exists. I already created this network But you should be able to see it and the way to verify that is just through a docker network LS command and you can see I have this Jenkins network already created so I can move on to the last step which is actually running the container command. And again, this is in my GitHub below.

I'm going to copy that over from my other screen and paste it in here. And this is just going to start the container. And you can see exactly what it's actually specifying here.

You can see that specifying the network of Jenkins. There's a couple environment variables here specifying the location of the certificates, the TLS version. and a couple map volumes and which ports should be published.

So let's go ahead and do a docker ps and you can see that the docker container is now running and it's listening on port 8080. So let's go ahead pull up a browser and see if we can get to this website. Alright so I have it pulled up here And you can see that it's on this unlock Jenkins command. This should be the first thing that you see when starting a new Jenkins instance.

And basically what it's telling you is you need to put in the administrator password. And that password is going to be at this location when you first install Jenkins. Now since we're running this on a Docker container, we're going to have to use the docker exec command to cat out this file. So I have that command saved in my GitHub.

so let's go ahead copy it paste it into the terminal here and it spits out my password so I'll grab that put it in and we're in. Now we're at a screen where we can install Jenkins. I'm going to install with the suggested plugins.

And this should go pretty quickly. It's just grabbing the most popular plugins that Jenkins uses, such as Ant and Gradle. A couple other things here.

Let's just wait for this to finish. And then we're going to set up our user account. All right. So we're at create your first administrator.

Go ahead and put in your details. I'm going to put in my details now and then hit save and continue. All right.

For this instance configuration, you can just leave at. default and hit save and finish and start using Jenkins. Alright so this is the Jenkins UI in all its glory.

I know it's not a lot to look at but it does get the job done. Let me zoom in a little bit here to make things a little larger and easier to see and let's go over what these items do. The first item here is your breadcrumbs so it'll make it easy to navigate through Jenkins and go down levels. something we're going to be using a lot when we're administrating our jobs.

The next thing is New Item. This is where you create your projects and pipelines. We're going to be going into it shortly. The next thing is People.

This is where you administrate user accounts. Build History gives you a history of all your jobs that have been run. Manage Jenkins has all your management stuff.

This is where you set up agents. This is where you install plugins. We're going to go in here as well and I'll show you the most popular menus that you'd be using as a Jenkins administrator. The My Views and New View is just a way to organize your jobs and have things display nicely.

Blue Ocean is a popular plugin for Jenkins that enhances your CICD pipelines. Once we have our pipeline created, we'll go into Blue Ocean and check out how it looks in Blue Ocean versus the regular Jenkins UI. For now, let's go into Manage Jenkins.

And you can see that this brings up quite a few different options. Basically, these are all your options for managing Jenkins. So at the very top, you can see there's some notifications here.

Let's go over them. The first one is just saying that building on the built-in node can be a security risk. This is just letting us know that we don't have any agents set up. So if we were to make a Jenkins pipeline, it would be running on the Jenkins master, which is not recommended.

We're going to be setting up some agents so this is something that we can ignore for now. The next one here is it's just a warning about one of our plugins. Basically wants us to go in and update our plugin so we'll just ignore that one for now and when we get to the plugin section we'll go ahead and fix this. Let's go over the main items that you'd be using as a Jenkins administrator.

So I'll scroll down here and get everything in the view. Alright, so let's see if we can speed run through the most popular items here. The first most popular one is Configure System. This is going to give you a lot of information about your Jenkins server and let you set some global parameters in regards to your Jenkins server.

So you'll probably spend a little bit of time in here. The next popular one is Manage Plugins. As a Jenkins administrator, you're going to be spending a lot of time in here because Jenkins is a beast when it comes to plugins. And over time, companies install plugins, developers install plugins, and different plugins break each other. When you upgrade Jenkins, plugins break.

So being a Jenkins administrator, you're going to be dealing with plugins a lot. So we're going to be spending quite a bit of time in here in this lab, and I'll show you how to administrate plugins. The next one is manage nodes and clouds. This is where you're going to go ahead and set up your agents as well as clouds like... Kubernetes, Docker, AWS, anything to do with agents will be in here.

The next section is the security section. A lot of these are pretty obvious. You can configure global security settings, you can manage users, and then you have managed credentials.

The managed credentials is probably the least obvious one in this list. This is where you would store SSH keys or API tokens. Now you don't have to use Jenkins as your credential manager.

You could use something like AWS secrets if you want, but Jenkins does have a built-in credential manager. So go ahead and use that if you would like. Down below we have some other pretty obvious things. You can get some system information about Jenkins. There's some logs, some load statistics.

I don't spend a lot of time here. At the bottom here you have a couple tools, mostly for troubleshooting Jenkins, but one that you may run into that you need to use is prepare for shutdown. So you would use this in a situation where you need to take the Jenkins server offline to perform some sort of maintenance.

You wouldn't want to just go ahead and reboot the Jenkins server or just shut it down because you would be interrupting current jobs that are running. So what you would want to do is set it to prepare for shutdown. And what that'll do is make it so Jenkins doesn't start any new jobs, it just finishes the jobs that are currently running.

Alright, so now that we know the main management features of Jenkins, we're ready to create our first project. So let's go up to Dashboard, and then New Item. And in here you can see there's quite a few different options, but the ones that you're going to be sticking with mostly is Freestyle Project and Pipelines. Pipelines are the more advanced style where you use the Groovy script.

We're going to be getting into that later on in the video, but freestyle projects are also pretty popular and they're a great way to start learning Jenkins. And if you're administrating Jenkins servers on the job, doing any type of consulting, you're going to run into freestyle projects, so it's going to be something you want to learn. So let's go ahead and create one.

We'll have to give it a name. So Now the first thing I can say here is do not create a name that has spaces in it. And the reason for this is because in the back end Jenkins is actually going to be creating a folder based on this job.

And it's going to be something that we have a look at so you understand the file structure of a Jenkins server. But for now just make sure not to use spaces and use something like underscores or dashes instead. So I'm going to call it my first job. Make sure Freestyle Project is selected and hit OK. Alright, so we are in the project settings of our first build that we're creating here.

Let me take you through the category of settings that you're going to run into here. The first one is just a couple build options at the top. You can ignore those for now. It's going to be something that you get into as you get more advanced into Jenkins. The next one is Source Control Management.

So you're almost always going to be using something like Git. And then you just put in your repository URL. Jenkins is going to go ahead and pull that repository down into your workspace and use that code. The next one is your build triggers.

So your build triggers is what is triggering your job. So popular options here is to have GitHub send a webhook to your Jenkins server. Now this can be a little more difficult.

If your Jenkins server is behind a firewall, you'll need to either open ports or use some sort of proxy service to make sure that webhook gets to your Jenkins server. Another way to sort of cheat the system is to use this polling SCM. And what this is going to do is it's going to have Jenkins reach out to GitHub and just check periodically. So that's one way to get around if your Jenkins is behind a firewall and cannot receive webhooks. Another option is to just build periodically and this is just the same thing as setting up a cron job.

You just set a schedule and your Jenkins build will run based on that schedule. For build environments, a popular option is to delete the workspace before the build starts. This just makes sure that you have a clean environment before your build runs and it deletes any artifacts that have been left over by Jenkins that were created during the last run of the job.

And then scrolling down, we have the build. These are your build steps that your build is going to go through. And then we have our post build actions. And these are just things that are going to happen when your build is complete. So some popular options here might be to send an email notification.

And if you had the Slack plugin, you could send notifications to Slack. So let's go over to build. And the most popular one that you're going to use is just to execute a shell. So this is just like bash scripting. So whatever we run here, the Jenkins server is going to run within its workspace.

So the simplest thing that we could do here is just echo hello world, hit save and then build now. And this is going to run our job. And we got an error here, so let's go check that out.

And it failed because I opened that git repository thing. So let's go back to our project. Go to configure.

And I left this empty. Let's just go ahead and set it to none. And that should fix the error that we have there.

So let's go ahead and save it. Hit build now. And now we can see that the job has run successfully. So we can click into it. And there we go.

It echoes hello world. So that's your simple hello world Jenkins build. Let's go back into the build. Just go up to back to my project and then configure and we're going to do something a little more complicated than just echo hello world.

Let's get into the available environment variables. So if you click here, just open it in a new tab, you can see all the environment variables that are set for Jenkins that you can use throughout your build and you're going to be using these variables quite a bit whenever you're creating jobs the most popular one that i like to use is build underscore id and this gives you the current build id i always use this when i'm versioning my docker images that i spit out from my build i like to specify the build id and then that way i know which build actually built the image so that's a popular one that i like to use Another popular one is the build URL. So you can see it here and you can see it gives the URL for the build. So that's a good one. So let's go ahead and put these into our job.

So to use the Jenkins variable I usually just go echo and we can see the build id of this Job is dollar sign and then I usually throw it into these two curly brackets and then I go build Underscore ID and then because we can we'll go the build URL is and then we'll put the build URL go ahead and save it and then build now and then we can go into our job and depending where you click the icon in jenkins it's either going to bring you to this screen or bring you right into the logs so let's go into console output and there you can see that it is saying hello world because we have that at the start of our job and then the build id is three and then the build URL is here. Now one thing that you may notice is it's spitting out everything twice. To explain that this is the actual command it's running with this plus sign and then the next line is just the standard out of the console.

So since we're echoing hello world that's sending standard out so that's the standard out. So that's why you're seeing everything twice in this job. Looking at this build URL So that basically just brings us here.

So this is a really good one if you're sending Slack notifications. You can send the build URL to one of your developers, letting them know that the build is done, and then they can click it and see everything that happened. So if you click it, you see it brings us here, gives us all the information about the build. Okay, so let's go back to our project and go to configure.

So the next thing that I want to do here is just show off the workspace. So if we go ls, this is just going to send the ls command to Linux. I'm actually going to go lsltr, and this should show all the files within the current workspace. Now since we don't have any files this probably won't output anything.

So let's create a file and we'll go echo 1 2 3 4. And then we will send the output to a file called test.txt and let's do an ls after that. We'll hit save, hit build now, and job number four is done. By the way, you can see there's two different links here.

This one brings you to the main build page. This one brings you directly to the console output so I always hit the check marks or the x's. So let's hit this. You can see that it ran the LSLTR first, there was zero files, and then you can see that it echoes 1234 out to the file, and now we have that test.txt. Now if we go back to our project, you can see we have this workspace option, and if we go into workspace, you can see that that test.txt file exists.

And there you go, click it. you can see 123. Now just for science let's go ahead and run the build again. And it's now done and if we go there this time you can see on the first LSLTR that the file already exists.

So basically what this means is we are not clearing out our workspace and the files from the previous build are already in our directory. So if we go back to our project We can change that by going delete workspace before build starts. And you can see here that you can add patterns to delete specific files. I'm just going to delete everything so we'll just leave the defaults.

Hit save, hit build now. The job is complete. Go in there. Now you can see the first ls shows that there's zero files. Then we create the new file.

Perfect. Now another thing that I would like to show you before we get into more advanced builds is the actual file system of Jenkins. So to do that let's hop into the terminal and I'm gonna run a command here to get into the actual docker container so it's just docker exec dash IT the docker container name and then bash this will give us a bash shell into the container And now we're on the actual Jenkins master. We're just in the root folder. So we'll want to go into the Jenkins folder.

And we actually specified it in our docker run command here. So it's this volume that we mounted. So var slash Jenkins home.

So we'll go in here and do an LSLTRA. Quite a bit of files and directories here. The one that we're interested in is workspace.

So let me clear the screen and then go into workspace. And now if I do an LSLTRA, you can see that we have a folder here called my underscore first underscore job. So this is the job that we created. So whenever you create a build, it's going to have its own workspace under a folder of the job name. That's why you don't want to create spaces.

And you can actually go in here and you will see all the files in here. So we can see our test.txt and cat it out and there you go. One, two, three, four. So actually SSHing into the Jenkins machine or doing a Docker exec into the container and having a look at the file system is something you're going to do. quite a bit with Jenkins, especially when you're troubleshooting builds and jobs.

Sometimes it's a lot easier to actually just go into the file system of the Jenkins server and have a look there. So a really great troubleshooting tool. Let's actually go back to the Jenkins home folder.

So we can actually just go cd tilde sign and that should bring us here. If you do pwd you can see we're in the Jenkins home folder. And if we look at the files again, you can see that there's other folders in here. So there's actually quite a bit of troubleshooting you could do within the file system. You can see that this plugins folder, this would be where you would have all your plugins, the updates folder where all the updates go.

And then you can see there's a couple like XML files for the Jenkins configuration, as well as logs. So this is a good place to go to troubleshoot your Jenkins master if you need to. Now that we've seen the file system of Jenkins, let's hop back into the Jenkins console and I'm going to go back to the dashboard. And you can see that we have this job coming up here nicely.

And you can see there's a couple things here. You can run the job. It tells you when it last successfully ran, when the last failure was, and the duration that it took the job to run. Now if we were to create some new jobs, they would show up here as well. So let's go ahead and do that.

I'm going to go new item. And what we're going to do for this one is we're going to clone down our report. repository and run a Python script. So we'll call this one my Python job, hit OK, and I'm going to go to this source control management, click get, and put in my GitHub repository.

So you should do the same if you're following along. There's a Python script in this repository that we're going to run, and you can see there's credentials here. Now this is a public repository so we don't need any credentials for cloning it down but if this was a private repository you would need to select your credentials or go ahead and add them. So if you're using a private repository go ahead and make sure you're using credentials for that. But for us we're okay so let's head down to the bottom and we're going to execute a shell and What we want to do here is I just want to see which version of Python is running.

And actually one quick troubleshooting step I want to run is let's just see if Python is installed. Hit Python on the Jenkins server and you can see that command not found. So let's try just Python3. And we can see that Python 3 is installed. So let's go ahead and go to our job and make sure we use Python 3. And then we want to run our script called hello world dot pi.

And I believe that's what it's called in our repository. Yes, hello world dot pi. So let's go ahead and run that one.

Go ahead and save it and hit build and check out the job. And there we go. We can see everything that it did. So you can see that it went out to my GitHub repository. It cloned everything down and then it ran Python three.

Hello world. And we got the output of our script. So something as simple as this is actually quite powerful.

Instead of us having to log onto a server to run a Python script, and you know make sure we have SSH to the server to make sure we can run the script. We can just create a Jenkins job, hit a button and we'll know that it runs. We can also set up triggers for this job to be triggered like webhooks or when a repository is updated as well as sort of like a cron schedule and we'll also always get a history of when that script was run. as well as full log output.

So this is just something that you can tie your Python scripts to and then just sort of keep track of whenever they're run. I also love doing this with Ansible and running Ansible playbooks instead of logging onto like a server and having someone run the Ansible playbook. I just set up a Jenkins job to run the playbook and then you have a full history of whenever that playbook was run. and if it was successful or not.

All right, so now that we have the basics of creating builds with Jenkins, let's get into more advanced topics like setting up agents and then building pipelines using the Groovy Santax. So I'm going to go back to the dashboard and then manage Jenkins and then manage nodes and clouds. And then on the left-hand side, there's two main options.

There's the new node and configure clouds. So if you go to new node this is how you configure a permanent agent. Basically this would just be any sort of like Linux or Windows server that you have that is sort of always available. You set it up as a permanent agent and Jenkins just connects to it via SSH and then distributes the jobs to it.

Now in my opinion this is sort of the older more deprecated ways of creating agents. Wait people are usually doing now is configuring clouds. So if you go to configure clouds, this is how you set up agents using cloud platforms such as Docker, Kubernetes, AWS. So now that we're in here we can see that there are no current cloud implementations available to us right now unless we go to the plugin manager.

And that just leads us to the plugin manager. So we'll go there. And you can see that it's filtering on cloud providers here and this is basically just a list of all the cloud providers that you can use for your agents.

Let's go ahead and install Docker, but if you're interested in Kubernetes or using AWS you could use those. So I'm just going to do Docker and I'll say download now and install after restart. And then it's going to go through everything. These look like just the first plugins that I installed during the setup. Down at the bottom here you can see Docker and it'll be activated during next boot.

So I'm going to go ahead and click this which will restart the Jenkins server. All right once the Jenkins server has restarted you should be asked to sign in again. So you can just sign in and then you'll want to go over to manage Jenkins.

and we should be able to go to our plugin manager and see that Docker is installed. If we go over to the installed tab here, we can see that everything to do with Docker has been installed. And if we go back to dashboard, manage Jenkins, manage nodes and clouds, then configure clouds, we can see that we have adding Docker as an option.

So we'll go ahead and add Docker and I'm going to hit Docker Cloud Details here. And there's a couple things that you need to do to set up Docker. The first thing is you need to set the URI of the host that is running Docker. So if you wanted to run Docker within the Jenkins you could just use like and then the port for Docker.

But if you want to run it remotely then you would put in the IP address of the remote server. Now I'm running Docker Desktop on my local PC here, so I don't want the Docker to run within the Jenkins master, I want it to run within my actual PC that's running Docker Desktop. So there's a couple things that we need to do here, and there's actually a really good Stack Overflow article that outlines how to do this.

I'll put it in the description below. And I also have details in my GitHub how to do it, and you can just follow along here on how to do it. So what I first want to do is launch a container running the Alpine SOCAD image. So I'm going to copy this command over from my GitHub and put it in.

And this should start up a container that's going to help proxy the connection from our Jenkins master container over to our local host here. So you can see that the container is up. I'm going to grab this container name and I'm going to do a docker inspect on it. And what I'm interested in here is the IP address of the SOCAT container.

And it's right here the So I want to forward my connections for docker to this IP address. So let's go in here and we'll go TCP, throw in that IP address, and then it's going to be port 2375. And then I'm going to hit enabled and test connection just to make sure that everything goes through OK. And you can see that it has connected properly.

Now, if I... put something incorrectly here like the wrong IP address you're probably going to get a connection error like the one that's popping up here and you'll just have to take whatever comes up here and go show details and troubleshoot it. Go to Google check to see what people suggest but most likely it has something to do with routing. Now let's go ahead and change this back to three and then just have it test and then go ahead and hit save and that'll bring us back here. Let's go back to manage nodes and clouds, back to configure clouds and we now have our docker cloud details set up.

But now what we want to do is create a docker agent template. So I'm going to hit this here and then hit add docker template and there's a few things that you need to set up here. The first one is the label and what labels are used for is for the master to use to determine which agent should run the build. So it should be something descriptive about the agent I'm just going to call it docker-agent-alpine and then I'm going to say that this should be enabled.

Make sure that you do the same if you're following along and then I'm going to take this label and just give it the same name. as the agent template. And then this is the important part.

This is the actual Docker image that you're going to be using. I'm going to be pulling one from Docker Hub, and it's going to be a Jenkins agent image running Alpine with JDK 11. Now, if you want to use your own image, you can point to it on Docker Hub, or you can set up a private repository. You'll just need to make sure that you put in your credentials.

So the Jenkins master can authenticate it to it and pull down the Docker image. Now for some container settings, we can leave that as default. Instance capacity, this is basically how many agents it's going to actually spawn. So you're going to want to set this to a number. I'm going to keep it really low for now, just because if you run into any issues, you might be spawning lots of agents and you don't really want to overwhelm your system.

Another really important field for us to fill here is the remote file system root. This is basically where your workspace folder is going to get created. This is your Jenkins home folder. So I'm going to call it slash home slash Jenkins, as this is the default that you should be using for all your Jenkins agents.

Now if we scroll down, I believe that's everything that we need to set here. Let's go ahead and hit save. And let's go back to our dashboard and let's go to my first job, configure.

And what we'll want to do here is select this restrict where this project can be run. And then we're going to say Docker agent Alpine. We can just select this one.

I'm getting a notification that this doesn't exist. This label doesn't exist, but sometimes it's just Jenkins causing trouble. You can see that the autocomplete had a space in it so when I remove the space that seemed to fix it.

Also sometimes if you go in and out of the job that will fix it as well. So go ahead and hit save and now when we build it should run the build on our docker agent. So I'll go build now. And you can see that it's looking for an agent that has the label Docker Agent Alpine. Looks like it's still looking for it.

So let's go ahead and troubleshoot this. Make sure that this is the right label. I'm gonna open up another tab here and just go to configure.

Go to a dashboard actually. then manage Jenkins nodes configure clouds take a look at our agent template we can see that's the correct name here and it looks like it's enabled so it should be good and if we go back back to here go to cloud details let's go ahead and test the connection the connections working good So everything here should be working fine. Let's go back into the job. And it looks like I was just being a little bit impatient as I was recording here. The agent picked it up and ran the job.

If we run in here, we can see it was building on the Docker remotely on this agent that it created. And the job completed successfully. And we can also go here, built on Docker, and then it tells you everything in regards to Docker. Now let's go ahead and have a look at our other job that we created. And you can see it's this Python job.

So what would happen if we went in here and restricted it to our Alpine image? Let's go ahead, and I think that'll fix itself. If we just hit build now, we'll give it a minute to build, go back into configure, and I guess I just didn't read it correctly. It's saying that it does match it, so let's go back and you can see that it did not run successfully. So let's have a look at why.

And you can see that it checked out the code, but it couldn't run the Python command because Python 3 isn't available. So the reason for this is because that agent template that we created is just pulling down a Jenkins image from Docker Hub that doesn't have Python installed. So what you would probably want to do is create your own image and that's exactly what I did and I have one available on Docker Hub that you guys can use as well. So let's go back to configure clouds.

under Manage Jenkins and we're going to set up a second agent and give it a new label. And then this second agent is going to run all our Python builds. So let's go to Docker Agent Templates. We have our first template here. I'm going to take the first part of this label and then scroll to the bottom.

and go add Docker template and then I'm going to give it a similar label but instead of saying Alpine I'm going to say Python. Make sure it's enabled, give it the same name as my label and then for the Docker image I'm going to use my Docker image that I created from Docker Hub. So it's just devopsjourney1 myjenkinsagents colon python1 And this is what the Docker file looks like if you're interested.

Now I'm just going to complete the other settings here. So instance capacity of two and then home slash Jenkins for the remote file system. That should be enough to get us started. So I'll go ahead and hit save. And then let's go to our dashboard, go into our Python job, configure it.

And instead of using just our. Alpine Docker image we're going to use our the label of Docker agent Python which has our Python image so we'll save that and we will run it and there you go if you're patient enough to watch you can see that it's selected the agent let's just go ahead and see and there we go the Python script ran successfully on our docker agent that had python installed on it. And there's actually a bug in my script that I didn't notice but maybe some of you guys did.

When you run python hello world it's saying hell world instead of hello world. So let's go ahead and fix that. And one thing that we can add into our build is to have them triggered automatically. So I'm going to go here and I'm going to configure And in our build triggers, I'm going to say pull the SCM.

Pull SCM is a way to have your Jenkins master monitor the GitHub repositories and just check for any changes. It's more simple than setting up webhooks, especially if your Jenkins master is behind a firewall. So that's the method we're going to take here.

And I'm going to paste in a schedule here. So it's star slash five star star star star. So this is very similar to setting up a cron job. What this star slash five means, it's going to do it randomly every five minutes.

And this is a best practice with Jenkins because you don't want all your Jenkins jobs going out once per minute all at the same time. This just helps the Jenkins master distribute when the jobs go out and look at their GitHub repositories. So we're going to keep it as is there.

Go ahead and hit save. And then I'm going to go into my GitHub here and I'll have a look at this script and I can go ahead and easily fix this just in GitHub. Change it to hello world and go ahead and commit the change.

And then I'm going to go here and just wait for the build to trigger. I have it running like. randomly once every five minutes so it should trigger here within the next five minutes.

I'm just going to go ahead and speed up the video. Alright so the job has completed and you can see if we go in here you can see at the very top that it was started by an SCM change. So this build was triggered automatically when we did a commit on our repository so we didn't have to go in and press the build button it just went ahead and ran the script.

So something that you can add to any of your repositories if you want the build to trigger when a change is made. Okay so so far in this course we've learned how to install and set up a Jenkins master as well as Jenkins agents. We've also been over how to set up a freestyle project and create basic builds. The next thing we're going to have a look at is setting up CI CD pipelines using the Groovy language. Now to get started with this all you have to do is go over to new item And then instead of going freestyle project you create a pipeline.

So we'll call this my first build Pipeline and we'll go ahead and hit OK. OK, so this looks very similar to what we've seen before with the freestyle project. But if you scroll down, you'll notice that you don't have a lot of the options that you did before, and that's because they're all going to be built into this pipeline script, which we need to define down here. Now there's two main ways that you can get started with doing this.

The first one is you can just create your pipeline script. directly into the Jenkins UI. Or the second option is to use what's called a Jenkins file and that's the preferred method. You just have a Jenkins file in your source repository and you point this pipeline over to that Jenkins file and it takes in your pipeline script there.

We're gonna start off just using this pipeline script but then later on in this video we'll check it into our source control and have Jenkins, check it out from there and run the pipeline that way. Now to get started here, I'm going to head on over to my GitHub repository and in there I have this JenkinsFile.template. So I'm going to take this, copy it and put it in here. And this is a good basic template that you can start off with for all your projects.

And if we just scroll to the top, you can see that it's got some nice syntax highlighting. This is in the Groovy syntax which follows a JSON format. And in case you are wondering, this is a declarative pipeline. This isn't the scripted format of a pipeline.

This is the declarative. So if you're looking up syntax for this, make sure you're checking declarative pipelines. Those are the ones that you should be starting out with when getting started with Jenkins.

But let's go through this pipeline. There's a couple of things that I want to break down. The first one mentioned before is everything is wrapped in this pipeline parameter. And then the first thing we do is we select the agent that we want this job to run on. So this is very similar to what we set up before to restrict which agent that the build runs on.

And we're specifying it based on the label. So for our pipeline, we want to set this to the label of our agent. I believe that was docker agent dash python and now that we have our label selected the next set of code here is the stages and within the stages we have individual stages. So this is a three-stage pipeline first to build next to test and the last stage is to deliver.

So this is good for a test build. Let's go through the steps. So you can see that for the stage build, each stage has steps and there's two steps within each stage.

The first step is just doing a basic echo from the Jenkins agent. And then the next step is to just run a shells command. And this is just a placeholder to also echo here. But we're going to be adding in our Linux commands to actually do stuff here. So I hope that makes sense.

It's going to make sense as we start running these builds and improving on it. So let's go ahead and hit save and let's go ahead and build. And then if we go into the build here, let's actually go back here and you can see immediately that the pipeline looks a lot different than just regular builds. You can see here that it's separated into the three different stages that we have set. build, test, and deliver.

And then you can see that the build is green, but test and deliver are red. So it looks like our build failed at the second stage of our pipeline here. Now you can go into the logs of each of these, and it'll tell you exactly what it was doing. So you can see the first thing it did was print the message building, and then it ran our shell script, which just echoes right now.

Let's go into our... test one and it says testing and then the shell script fails and it looks like it's an unterminated quoted string so that should be easy enough to fix let's go into configure and build is good it was this one the test stage so we'll fix the quotation And our deliver stage looks okay. Now the reason that deliver failed even though it looked okay is because test was an upstream stage and basically if an upstream stage fails your downstream stages are going to fail as well. So let's go ahead and hit build and I'll stay on this page this time and here you can see that it's going through the stages and since our build is so quick it just immediately updated but if you're doing a longer build you would see sort of like a progress bar.

All right so that's pretty good. Let's up our game by using a Jenkins file and just improving this pipeline. So I'm going to pull up my Visual Studio code here and I'm just going to take this, copy it, paste it, and then just rename it to Jenkins file.

And I actually need to fix this quotation here because it was missing. And this should be good enough for our job. But I actually want to improve our job before I upload this to GitHub.

And the improvement I want to make is to have Jenkins pull the SCM, which we did with our previous project. And basically this means that Jenkins will reach out to GitHub. And if there's any changes on the repository, it's going to go through the build.

So... I just looked up this syntax by going through a Stack Overflow article and this is it looks like the one that we want and by the way this is how most of us DevOps engineers work it's just searching for what we want on Google and then finding the Stack Overflow article and putting it in DevOps is just like building Legos so anyways this should work I want it to pull Every five minutes actually, so I just manipulated the parameters So it will pull once every five minutes if there's new code on github It's gonna run the build so I'm gonna take this and I'm going to push it out to github here Just do my commit And then within my actual project I'll need to convert this. You can just get rid of that and instead of using PipelineScript we want to change this to PipelineScript from SCM. We'll say git.

We'll snag this repository URL. If you're doing this on your own make sure to change this to your GitHub URL. And if it's a private repository, you're going to have to use credentials. Mine's public, so this will be fine.

And then the script path, we just have it set as Jenkins file. But you can name the Jenkins file anything that you wanted and put it in any directory that you wanted. You just need to make sure that this was up to date. So this should be good. I'm going to go ahead and hit save.

And I'm actually just going to trigger this one manually just to get it going. but for future builds next time we do like get commit and push to github this build should trigger automatically so let's just go ahead and make sure the build runs using the jenkins file i'm just going to hop right into the console output so it obtained the jenkins file from get so we're looking pretty good here And I actually forgot to update this, so this job is just going to run forever. Let's go ahead and change my template. Sorry, not my template, change the actual Jenkins file. And change this to Docker Jenkins, Docker Agent Python.

Alright, I have the memory of a goldfish. Let's go ahead. These changes look good. I'm going to put it up here and just go Undated Jenkins file and I'm just gonna push this way. Double-check GitHub.

Make sure our changes are there Alright, that looks good to me. And this should run. Let's just go ahead and cancel this build. And I'm actually just going to go grab a drink, wait five minutes, and see if my build automatically triggers.

Alright, so I left it for about ten minutes here, and it didn't look like it automatically triggered. If we go into Configure... You can see that it picked up these poll SEM settings from the Jenkins file and It looks like it should have run I'm just gonna be impatient here and I'm gonna hit build now and In here my Jenkins file, I'm actually just gonna change this to star and then this way it'll just run once a minute and that's fine for our lab environment.

Anyways let's go check on the build and see how it's going. It looks like it was successful. It ran on the docker agent Python and everything ran successfully and if you look up there it used the Jenkins file to do it.

Now one thing you may notice is the output of this changed and that's because an additional stage was added. It actually added the checkout stage and the reason it did this is if you go into configure underneath the pipeline we're saying pipeline script from SCM. So when you do that it automatically adds the step to clone down this GitHub repository.

So that's the reason for that. One thing that you'll notice here is it cleared out the history of the old jobs because the additional stage was added. But that's okay, it's just one of the little quirks of Jenkins. Let's go ahead and build out our pipeline more. So I'm going to go back into Visual Studio Code and right here we have our three stages, the build, test, and deliver.

Let's actually flesh this out. So you can see in the repository I do have this application called my app and if we just look at it you can see it's a python file and as you can see this is a pretty simple script what it's doing here is it's first importing the fire library and then it's just creating a cli application that returns hello world now if we were to run this script on our Jenkins agent it would fail because it doesn't have the fire library So let's actually go to our Jenkins file and for build instead of echoing let's say cd into my app and then go pip install dash r requirements dot text. So now the Jenkins agent will make sure that it has the fire library installed and then for testing Let's go ahead and run our script. So we'll go python3 hello.py and there is actually two ways that I could do it.

It should work if I just run the python application by itself, but it'll also accept a parameter. So let's run it both ways. So I'll go python3 Hello.py name equals brad and actually will need to be in the my app directory.

So that's perfect. So the first thing it's going to do is install the requirements for this application. And the next thing it's going to do is run the application and make sure that it's running OK. So I'm going to save this and push it over to my repository.

And let's go here. Oh, and it looks like it's already building our job here. It was automatically triggered through SCM. Checkout went good.

Now it's going through the build. and test and deliver. Alright let's have a look at how these look.

So console output you can see the cloning went through fine. The next thing it did was it did pip install requirements.txt so it installed the FHIR library and then it went into the testing stage and then it ran python hello hello world and then it ran it with a parameter brad hello brad and you can see both of them worked so let's go ahead and have a look at this in blue ocean and i'll just show you how the interface of blue ocean looks so much nicer than this sort of outdated jenkins pipeline so if you just go to open blue ocean You can see that the pipeline has all our different stages here. It started, build, test, deliver. And if you click on each individual stage, you can see exactly what happened in these stages.

So you can see the checkout from version control, our echo message, and then what it actually did. And went into the MyApp, installed the requirements.txt. So Blue Ocean is pretty good for giving you a nice interface so you can go in and look at the build and have a look at what happened in each of the stages of the build. A lot of your job as a DevOps engineer is going to be troubleshooting these pipelines, so having a nice interface to do it is always good. And Blue Ocean just really cleans things up, as you can see.

So that's basically all I want to show for Blue Ocean. If you followed along with this video then you should have it available to you as well to go in. And here's the main page of Blue Ocean. So we can see our actual pipeline here and if we look we can see oh it was started by me basically when I clicked the go button and then this one was automatically triggered and yeah you could run the build from here if you wanted you could disable the build and if you just go to configure it just brings you back to the old Jenkins.

interface. So that's all I really wanted to show for Blue Ocean. It's a really cool thing to get into, especially when you get to the multi-branch pipelines.

But for our purposes, it's just a nicer looking Jenkins interface that'll help you troubleshoot Jenkins jobs. So that was your intro to Jenkins. In this video, we went over the key skills such as installing and setting up a master server, setting up Docker Cloud agents.

We also covered how to set up and manage freestyle projects. And lastly, we went over setting up pipelines using the declarative language Groovy. I hope you enjoyed this video course and found it gave you practical skills on how to use Jenkins. If you have any questions, leave a comment below.

And if you haven't already, please check out my other videos and subscribe to the channel. Thanks again for watching and I hope to see you in the next video.

Transcript for:Getting Started with Jenkins Automation

Transcript for:
Getting Started with Jenkins Automation