Jenkins is a popular open-source automation tool that can be used to automate the build process for software projects. In this article, we will show you how to set up a Jenkins build server so that you can easily automate your software development process. First, you will need to install Jenkins on your computer. You can download the latest version of Jenkins from the Jenkins website. Once you have installed Jenkins, you will need to create a new project. To do this, click on the “New Project” button in the main toolbar and enter the following information: Name: My First Project Description: This is my first project. I am not sure what I am doing! Location: C:\Jenkins\workspace\My First Project My First Project This is my first project. I am not sure what I am doing! C:\Jenkins\workspace\My First Project Click on the “Create” button to create your new project. Once your project has been created, click on the “Configure” button and enter the following information: Select “Builds” as your project type . This will allow Jenkins to track all of your builds and report statistics about them. Select “Java” as your language . This will allow you to use Java code in your builds. Click on the “Configure System” button and enter the following information: Select “Linux/Unix” as your operating system . This will allow Jenkins to run on Linux or Unix systems. Enter “/usr/local/bin/jenkins” as your path . This will be where Jenkins stores its files (by default, it stores them in C:\Jenkins). Enter a name for your build server . By default, this is set to “jenkins”. Click on the “Save Changes” button and then click on the “Start Server” button ..
Automation limits bugs due to code other team members write, as the code was checked out. In order to achieve this benefit, a high degree of automation and orchestration is necessary. Enter Jenkins.
Jenkins is one of the most popular and flexible open-source orchestration tools out there. No matter if you working on a legacy monolith or micro-services, on-premise or in the cloud, Jenkins can help.
In this article, to understand how Jenkins build servers work, we’re going to walk through the basics of how to get a Jenkins server running. We’re going to poll a local Git repository, and run some PowerShell code when a change is made to that repository to get a sense of the workflow.
Prerequisites
We get hands-on in this article. If you’d like to follow along, be sure you have a few prerequisites in place:
A Mac, Linux, or Windows device with: Java 1. 7 or higher (Jenkins runs on Java) A package manager (Chocolatey, Homebrew, apt, yum, etc) A web browser (Chrome, Firefox, or any Chromium-based browser work best) Git (Can install this with the package manager) A Git repository
Installing Jenkins
You can install Jenkins in numerous ways, each of them fitting a different platform and use case. If you are building a production server, you may want to consider using a different method from the one shown, but the easiest way to install Jenkins is with a package manager.
On Windows, you likely use Chocolatey, on MacOS Homebrew, and on Linux it depends on which distribution of Linux you are using.
Once you have installed Jenkins, you can access it right from your web browser. Open your browser and navigate to localhost:8080 , and you see Jenkins starting or waiting for an initial password.
localhost is referring to the Jenkins service that is now running on your device while port 8080 is the default Jenkins UI port.
Finding the Administrator Password
On the first page, Jenkins writes a one-time password to a file, then gives you the location of the file. This process makes sure you have access to the file system of the system you installed it on.
Get the password from this file, the enter it in the Administrator password box shown in the screenshot below to continue.
Installing Initial Plugins
Next, Jenkins is going to ask you if you want to pick and choose the plugins to install, or use the recommended defaults. Plugins are how Jenkins interacts with other components and services. You install more plugins later, but for now, select the defaults.
Setting Up an Admin User
After a few minutes, you need to setup your first Jenkins admin user. This can be changed later, but it’s important to pick one that you will remember at least during the setup process, like the one below.
Defining the Jenkins URL
Next, you’re asked to set up the Jenkins URL. This process is not going to do any DNS or domain registration and has no effect on how you access Jenkins. There’s no need to worry about the URL for this walkthrough. But the URL will be used in any webhooks and environment variables that Jenkins creates.
Once you click on Save and Finish, you’re taken to an empty Jenkins page like this one below.
Installing Plug-Ins
Now that Jenkins is up and running, you should know something about it: out of the box, Jenkins doesn’t do very much. To get the most out of Jenkins, you must install plug-ins.
Plugins are open-source packages that interact with other programs and services within Jenkins.
You can find plugins for anything from additional version control systems, to cloud providers, to Chuck Norris.
PowerShell is a part of the requirements of this article. As such, you need to install the PowerShell plugin and maybe the Chuck Norris one, too.
Click on Manage Jenkins in the menu on the left, then find the puzzle piece icon that reads Manage Plugins. Then, under the Available tab, you can browse around and see what’s available.
Click on the checkbox next to the PowerShell plugin and click Install without restart.
Setting Up a Git Repository
The next thing we need to do is set up our git repository. Jenkins polls this repository for changes to run our build. Get the repository URL and clone it, but save the URL because you need it in the next step.
Back in Jenkins, select New Item from the top left corner, then click on Freestyle Project and give it a name. A good name has to be unique to Jenkins, but also describes quickly what task it is doing on which project.
The next page you’re taken to is the Configure Project page. This may look overwhelming, but don’t worry about it right now. Even in production, you won’t use most of these because while every one of these options has a use case for someone, not all of them will fit your use case.
As you scroll down the configuration page, notice the many available options. Below, you’ll find each option and the value that should be provided for this demonstration.
Source Code Management
Click on Git, then enter your repository URL in the Repository URL field. Leave the rest of the settings as default. This is going to tell Jenkins to poll that repository for any changes on the master branch as that’s the default setting.
Build Triggers
Select Poll SCM, then enter * * * * * in the Schedule field. This is a cron timer that polls for changes to that repository every minute.
Build
Under the Add Build Step dropdown, select Windows PowerShell and enter Get-ChildItem $ENV:WORKSPACE in the Command field. This command uses a built-in Jenkins variable (which is covered more in-depth shortly) to print out a list of files from the repository you are looking at.
(Optional) Post-Build Actions
If you installed the Chuck Norris plugin earlier, select Activate Chuck Norris from the Add Post-build step dropdown to add the Chuck Norris plugin’s visual effect to the job. Jenkins does not actually activate Chuck Norris, Jenkins just looks for his approval.
Running the Build
All Jenkins builds take place in a workspace, which is a directory on the Jenkins server. The test project that you defined above clones the repository from the git URL into that workspace, then runs the build steps as a .ps1 script.
Earlier when you entered $ENV:WORKSPACE in the build step, you may have wondered where that variable is coming from. Jenkins provides some environment variable at the runtime of each job, including $ENV:WORKSPACE, which points to the path of the cloned repository.
Now that your job is configured, it’s time to test it. You can run it one of two ways: Either push a new commit to the repository and wait for Jenkins to poll the change, or press the Build Now button on the left side of the page. Whatever method you choose, it triggers a new run of this Jenkins job, which means your home page should now look like this:
For one final sanity check to make sure our job ran successfully, click on the build number under the Build History. This page shows you some details like the changes that triggered the build, what the git commit ID is, and which user pushed those commits.
For even more details, click on Console Output on the left side of the screen and you’ll see each command line step Jenkins took while running the build.
Because this build also included a Get-ChildItem on the Jenkins workspace, the output from that cmdlet at the bottom of the console output similar to the one below is shown.
Summary
Now that you know how to setup a Jenkins server, install plugins, and run a job, you should take a look at the available Jenkins plugins from the Manage Plug-Ins page mentioned earlier. Not all of them will fit your needs, but they all fit some need and might be worth knowing about.
If you have GitHub enterprise, you can connect your GitHub account to Jenkins to do things like require status checks before merging to master, automate deployments from source, and run a CI pipeline against any new changes to code. Have fun!
