DevOps Digest 204: Configuring for Build Automation with Jenkins
After creating our sample application last week and getting it stored in our version control platform, Perforce Helix, we’re finally ready to create a Jenkins project to build it every time we submit a change into the mainline. The challenges we overcome should provide a solid foundation for discussing more advanced CI topics later. But this week, we’ll demonstrate common problems and pitfalls when configuring projects in Jenkins so that you’re better equipped to handle them.
Configuring Projects in Jenkins
Retrieving Source Code from the Command Line
Run a simple p4 clean command in the root folder to verify that nothing is broken and that we can actually retrieve our source code and build it straight from the command line. This is what we get when we execute the command in a basic shell:
The clean command deletes old build artifacts and other “clutter” that has accumulated since the last build, ensuring that the current folder only contains the latest version on the server.
The error message suggests that the command didn’t work. When the Helix Command-Line Interface attempts to execute a command that needs a workspace, it uses the name of the local machine as a default if it doesn’t “know” what else to use. More precisely, it uses the value of the “COMPUTERNAME” environment variable on Windows, or the name of the host on other operating systems.
Earlier, we looked at the configurable on our Helix server and enabled the DVCS features. There are a number of environment variables that similarly serve to inform client-side operations, and the P4CLIENT variable specifies the current workspace name. The set command output shows us which of them are set:
There are several, but the P4CLIENT variable isn’t one of them. Using a command to set that directly means that any use of P4 would pick that setting regardless of its current directory.
Thankfully, you can use per-directory settings, with the variable P4CONFIG. Set P4CONFIG to the name of the text file we already created, and use the clean command again. It will complete successfully now.
We use a file named “p4config.txt” because that’s what Helix native DVCS features use when initializing a new repository. Setting the P4CONFIG variable to that file name tells P4 to look for that file when executing commands. Let’s look at the contents of the file.
We set variables for the ignore file we discussed earlier: the user, the server to which to connect, and the name of the workspace to use. The command completed successfully because P4 read the contents of that file and “knew” the proper workspace name to use.
Building a File from the Command Line
Now that we can access our VCS from the command line and have the latest version of source code, we can do a build. MsBuild.exe is the name of the tool we want to execute, and we want to pass it a couple of arguments specifying the configuration and platform for which to build. The desired configuration for this stage is “Debug”, while the desired platform is “Any CPU”. We see those arguments in the screenshot below, along with the name of our solution file.
The build fails because Windows can’t find the tool we’re trying to run. By default, VS2015 respects your existing configuration at installation and doesn’t litter your executable path with its tools. To gain access to them, we first need to configure the environment using a batch file. The following screenshot shows how things change once we execute the batch file to set up the environment for development and then re-try the build command.
Unfortunately, the build process is still failing. Both error messages concern NuGet packages referenced by projects in our solution that aren’t present on the drive.
NuGet is a tool for consuming third-party or internal NuGet packages at build time, and it’s terribly useful for shortening your build cycles and CBD. Currently, the packages aren’t downloading at build time.
This is the reason we did not let VS2015 build our project when we started our application. Microsoft has changed how NuGet works and integrates with the integrated development environment (IDE) and the command line over the years. For now, we’re going to get it working on the command line for our builds with a quick and dirty approach.
To get the NuGet utility, we need to download the latest version (v3.4.4 at the time of this writing) from the NuGet distributions page.
Once you’ve downloaded the file, create a new build folder in the root folder we’ve been using and move the NuGet utility there. Remember, if you don’t have all the pieces required to build your app, then you might as well not have the source code. Helix is your single source of truth for every, single piece of content.
But we’ll come back to that. First, we need to make sure that the tool we downloaded can do the job. You can’t see the command invocation in the screenshot below, so I’ll provide it here. I used the NuGet utility from our new Build folder with a simple command: nuget.exe restore Solutions\DevOpsSample.sln .
That tells the NuGet utility to restore all packages required by the specified solution file and store those packages under the solution file folder. The following screenshot shows that the restore process completed successfully after downloading 42 packages.
Having restored the requisite NuGet packages, we can execute the build command again. This time, things go better.
The original command was long, but it succeeded. Now, we can automate the process of getting the source from Helix and building it with VS2015.
Adding the Build Folder to Version Control
Lest we forget, however, we added a new build folder, which contains the NuGet utility, but haven’t yet added it to version control. It’s easy to add a file to your version control via the command line and only takes two commands in the following screenshot.
The add command appends the NuGet utility to the default changelist as a new file, whereas the submit command sends that default changelist to the server with the given description.
Many users prefer to use the Helix Visual Client (P4V), of course, but for such a simple operation the command line can actually be faster. DevOps staff should take time to study P4 tips and tricks and to make your job much easier in the end.
In the next issue, we’ll round off our chapter on continuous integration basics by triggering a build-per-commit. Stay tuned next week for DevOps Digest 205!
You Ask, We Answer
As previously mentioned, this is your roadmap to creating a successful DevOps pipeline. Don’t understand something? Just ask. Need to dive a little deeper? Send an email to firstname.lastname@example.org with your questions. Then, stay tuned for a live Q&A webinar at the end of this series. Get DevOps Digest Sent to your Inbox
You don’t need to remember to check back with us each week. Instead, get the digest delivered directly to your inbox. Subscribe to our 25-week DevOps Digest and we’ll get you where you need to go, one email at a time.
Catch up on DevOps Digest:
See Perforce Helix in Action!
Join us for a live demo every other Tuesday and see the best of Perforce Helix in 20 minutes. Save your spot!