In the previous part of this series, you learned how to set up the required software on your VM, in order to turn it into a Jenkins based build server.
In this part, the real fun begins, where going to get Jenkins to build and deploy our project for us.
Jenkins First run
Once your build server is up and running, you should be able to ender the IP address of your server into your browser on port 8080, using the following URL
http://myserverip:8080/
Replace 'myserverip' with the IP address or name of your VM/Server set up.
If everything has worked, you should see something similar to the following:
The Jenkins team have made Jenkins fairly secure right from the word go, and you can't even run it until you enter the key it's generated as part of its initial install.
Using the midnight commander tool you installed in part 2 and browse to the folder mentioned on the Jenkins page you'll find a file with a string of hex digits in it.
In midnight commander you can press F3 to view the file, but you're probably better off pressing CTRL+O to open a command line, then typing
Cat initialAdminPassword
To type the contents of the file to your shell screen.
Copy and pasting tends to work better from the main command line screen than from inside an app such as MC, when your pasting to/from a virtual machine.
However you manage to copy the string of hex bytes, it's that string that Jenkins is expecting to be entered into the text box in the web page your browser is displaying, marked 'Administrator Password'
Following on from this, the next thing you'll get asked will be to create the first user in the system. Just as with the first user of your OS this first user in Jenkins will have admin rights and will automatically be allowed to configure and setup Jenkins and the jobs it runs.
You can add other users later from the Jenkins settings if you need to, but right now the user you enter here will generally be the one for the person tasked with looking after and maintaining the server.
Plugging in the plug-ins
The next screen you'll see will be the setup wizard, part of this will be to select recommended and needed plugins.
One plug in we will, need, for this part of the series will be the HTTP Request plugin, so use the "available" tab and type "HTTP Request" into the search box to find it.
Other than that, it's up to you which plugins you choose to include/exclude, however if this si the first time you've used Jenkins, then I would strongly advise that you just go with the default recommended set.
Once the setup is finished, you'll arrive at the main Jenkins screen
My screen in figure 4, has already had projects added, then removed so it may look different to yours, you're likely to have a large notice in the middle of the page telling you, that you have no projects and inviting you to start one.
Adding the core
In the upper left corner you should see a menu item marked "Add new item", if you click on this it will take you to a page where you can start to define your project.
Depending on the plugins you installed, this list may be slightly different, but the one you will definitely have, and the one we need for a dotnet core build, is the "freestyle project" type.
In the very top field, give your project a name, select "freestyle project" by clicking on it, and then click ok to continue.
This will bring you to the project configuration screen ready to define the steps to build your project.
The first thing you're going to want to do is to add a description for your project, so go ahead, create something interesting in there to test with.
If your project is on github, then you can tick the github checkbox and that will ask for the URL of your project and set things up for you.
In my case however, I'm using my own git server so feel free to proceed as you see fit.
If at any time you don't know what an option is for in Jenkins, clicking on the blue help circle will expand a help section for you explaining everything about the option. For first time users it's actually worth going through and reading all the help parts as there is a lot of great information contained within them.
I'm just going to include a description, tick nothing and scroll down to the source code management section.
Under source code management I'm going to select "git" and configure it to use my local git server.
I already have a test project setup to use here, and running your own "git server" is a topic for another time.
For those who are interested however, I use "Bonobo Git Server" (https://bonobogitserver.com/) it's a full framework ASP.NET app that runs under a standard IIS/Windows server implementation and is great for small teams wanting to keep their source control on site.
I've already set my server up so that my Jenkins install has an access user name & password, so the only thing I need is the git url, we plug that and the username/password into Jenkins.
You'll need to use the "add" button to add a set of credentials the first time you do this, but from that point on, you'll be able to just click on the credentials drop down and select a set to use as Fig 8 shows.
Once you have a working set, the error will go away and the dialog will return to normal
With the repo address set up, the next part that needs our attention is the build triggers.
Jenkins can be triggered to build your project in a staggering number of ways, and this list will change depending on the plug-in's you choose to install.
For us in this example however we are going to "Poll SCM" periodically (approx. every 5 minutes) and ask the git server if there are any changes.
Tick the "Poll SCM" box and open the options to define your polling time.
The schedule box takes a time definition in linux "cron" time format, which for 5 minutes looks like this
H/5 * * * *
Basically what this says is "every 5 minutes in the hour, for ever year/day/minute/second (4 stars)", if you know the details of a cron job time formatter, then you can set the polling schedule to some really crazy stuff, such as the second hour, every 4th month for 20 minutes only, in our case however, just copy the H/5 and 4 stars into the schedule box and set it to every 5 minutes.
The next part is configuration of your "Build Environment", again as with everything else in Jenkins, what appears here will depend on the plug-in's your using, but typically the only one I ever tick is the "Add timestamps" option.
Adding timestamps to the console helps greatly, especially if you have a very busy build server, because then you can match build output to actual dates/times of check-in's and build steps.
The builders start to build
Finally we'll get to the last part, the build and post build steps.
If you click on the "Add Build step" button you should get a drop down menu that allows you to select a build type. For us to build a dotnet core app if either needs to be "Execute Shell" or if you're running on windows then you'll need to use "Execute Windows Batch Command".
Whichever of the 2 you select the contents in them will be exactly the same.
You may also see an option to build an MSBuild project, this can only be used if you A)Have the MSBuild tools installed on the server (Either a full version of visual studio, or the tools pack specifically for installing on build servers) and B) If your project uses a full fat old version of full .NET to build. I have personally used them to build an SLN file for a dotnet core project, but it was tricky to set up and the build was quite fragile.
Where using an Ubuntu server so we'll select "Execute Shell", this will give us a text box to type the contents of our shell script into.
Into this build script we simply enter the things we would normally type at the command line to build our project, something along the lines of:
dotnet restore
dotnet build
Notice I've not included a "Dotnet run" in there.
This is deliberate as we don't actually want to run our project, only to build it and make sure that build didn't cause any errors.
The link just below the box will show you the things you can place in the script to refer to things like the build name, its folder location and other stuff. It's worth learning what's in there, as you'll likely need them once your build starts getting more complicated.
We won't need any for now, as the project where building is very simple.
For now your build step should look as simple as this.
At this point let's save our build and test it.
Click save, make sure your project has something in its repo to build, then from the left hand menu in Jenkins click "build now"
All being well your project should be checked out and built.
If you hover over and click on the number next to your build, you should get a menu up that allows you to view the console output.
The console output is the first place to look when working with Jenkins if something fails, as the reason will usually be in here.
In our case everything built fine and with no errors.
In the next and final part in this mini-series I'll show you how to expand your build script to deploy your app to run behind the nginx reverse proxy server, have the OS automatically start it and test that it's up and running and ready to server requests.