DevOps Digest 305: Automating Our Debug Build
In DevOps Digest 304, we created a development stream, the first step in getting a debug build working and isolating it from the mainline. Now we need only make a couple more updates in Jenkins.
You might think you could simply enable SCM polling in Jenkins, but all you’d be doing is waiting indefinitely in frustration. Giving Jenkins a polling interval will seem to work, but the polling log will show you regular polling that detects no changes, which is obviously not what we want. What we actually need to do is perform three steps:
- Create a new Perforce Helix credential in Jenkins.
- Update our Pipeline script to use the Perforce Helix plugin.
- Execute a manual build to get it all working.
The short version of the story is that simple SCM polling can’t work until the Perforce Helix plugin for Jenkins has had a chance do its thing, and to date we haven’t used it. We deliberately chose to sync our source code the old-fashioned way to illustrate several points, but we could do better. Now we’re going to leverage the power of the plugin.
First, let’s create the new credential. From the top-level Jenkins dashboard, click the “Credentials” link on the left, then the “(global)” domain, and then “Add Credentials”. Choose the option to create a “Perforce Password Credential” and fill in details like:
Notice the word “Success” to the left of the “Test Connection” button. It’s always good to test your connection to the Helix server when creating credentials, and that text (“Success”) is the result of clicking the button. That tells us that the details we supplied work properly, so clicking the “OK” button will add the credential for our use.
With that new “P4” credential in place, edit the Pipeline script as seen below.
The plugin lets us replace all former batch-file ugliness with a single line of script. In case you’re wondering about the full text, we used the “Pipeline Syntax” link at the bottom of the screenshot to generate it; the full text is as follows:
p4sync charset: 'none', credential: 'P4', format: 'DevOpsSample-Main', populate: [$class: 'AutoCleanImpl', delete: true, modtime: false, parallel: [enable: false, minbytes: '1024', minfiles: '1', path: '/usr/local/bin/p4', threads: '4'], pin: '', quiet: true, replace: true], stream: '//DevOps/Development'
That is a textual representation of the options chosen in the Pipeline syntax generator. It looks obscure at first glance, but in time you will easily pick out the more salient pieces. For the case at hand, we can see that it’s using our new “P4” credential, the recently edited “DevOpsSample-Main”, and that it’s syncing against the “//DevOps/Development” stream we just created. We also removed the block of code previously used to load a regular Jenkins credential into the environment. Using the plugin is much clearer and cleaner.
Pipeline changes aside, we also need to set a polling interval for our project. How often you poll for a debug build depends largely on balancing the pace of your organization against the load on your servers, but here we’re going to have Jenkins poll the Helix server every minute. This is easily accomplished by scrolling back up to the build triggers section and updating it as follows. Long-time *nix users will recognize those five asterisks as the standard crontab format.
Now, save your changes to the project and then click the button to start a manual build. This gives the plugin a chance to store the most recent changelist number so that future polling will work. In fact, once you’ve done such a build, the polling selection in the menu will update its description to “Perforce Software Polling Log”, which is a sign of success for the plugin.
Having updated our Jenkins project, let’s have a little fun and test our automated debug build by leveraging the great DVCS features in Helix to add a “Readme” file. The following screenshot shows the series of commands executed to do so on a completely different machine. Log in with your Helix server, clone the new Development stream, add a new file, reconcile work, submit, and push back to the server.
By the time we switched back to Jenkins, it had already polled the server and started a build. Below, in the linked text “Started by an SCM change”, you can see that drilling down into the build result shows that this the first time we’ve triggered a build because a change in the source code was detected.
Whew! It’s been a long road to get here, hasn’t it? Nobody said DevOps was going to be easy, only that it was going to be rewarding. And now that we’ve got some basics in place, we can move on to more advanced topics starting next week, in DevOps Digest 306.
Next week we will add scripting to the build process for encapsulation and information hiding. Issue 306 will also serve as a precursor to adding unit tests and code coverage to further enhance our continuous testing processes.
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.
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!