The Puppet PDK provides us with a framework for repeatable Continuous Integration. We'll be taking our bare bones module and converting it with PDK, and then we will begin by using PDK validate to replace our basic puppet parser validate command. Because the PDK is available on our Jenkins master, all PDK commands will also be available for use.

Our first step will be to change branches so that we don't impact the master as we're adding new code:

[root@pe-puppet-master profile]# git checkout -b pdk
Switched to a new branch 'pdk'

Next, let's convert our existing module with the PDK convert command. We'll be prompted with a series of questions, mostly aimed at publishing modules to the forge. The final question asks which operating system this is relevant to and actually does help form our test bindings, so we'll minimize this to just the targeted operating system: Red Hat-based Linux. Simply run pdk convert and follow the prompts.

The default PDK template contains three files not relevant to us: .gitlab-ci.yml, .travis.yml, and appveyor.yml, which are used for other CI systems. We'll then add our new files and commit them into a new code commit:

[rary@workstation profile]# rm .gitlab-ci.yml .travis.yml appveyor.yml
rm: remove regular file ‘.gitlab-ci.yml’? y
rm: remove regular file ‘.travis.yml’? y
rm: remove regular file ‘appveyor.yml’? y
[rary@workstation profile]# git add -A
[rary@workstation profile]# git commit -m 'Initial PDK integration'
[pdk 7eb5009] Initial PDK integration
 10 files changed, 350 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 .pdkignore
 create mode 100644 .rspec
 create mode 100644 .rubocop.yml
 create mode 100644 .yardopts
 create mode 100644 Gemfile
 create mode 100644 Rakefile
 create mode 100644 metadata.json
 create mode 100644 spec/default_facts.yml
 create mode 100644 spec/spec_helper.rb

Then, we'll change our Jenkinsfile Test stage to use the pdk validate utility:

pipeline {
  agent any
    stages {
        stage('Test') {
            steps {
                sh '/usr/local/bin/pdk validate'
            }
        }
    }
}

We'll push that back up to our remote repository with our Git workflow, and our Jenkins instance will automatically pick up our job on our new PDK branch after sending it remotely with git push origin pdk. Back on our profile page, we will now see a new branch:

The inside of this PDK branch should appear similar to our previous branch, but we want to inspect the logs of our test. Inside, we'll see that a few puppet-lint warnings were triggered, but did not fail the build. Puppet lint warnings by default provide an exit status of 0, allowing your build to still pass:

warning: puppet-lint: manifests/jenkins.pp:1:1: class not documented
warning: puppet-lint: manifests/jenkins.pp:14:12: indentation of => is not properly aligned (expected in column 13, but found it in column 12)
warning: puppet-lint: manifests/jenkins.pp:15:12: indentation of => is not properly aligned (expected in column 13, but found it in column 12)

Before we do a pull request of this code into master, let's clean up our lint warnings by adding a comment to the top of our manifest, and aligning the arrows within the PDK package:

# Jenkins Profile
class profile::jenkins {

  class { 'jenkins': lts => true }

  package {'git': ensure => latest }

  file {'/tmp/pdk.rpm':
    ensure => file,
    source => 'https://puppet-pdk.s3.amazonaws.com/pdk/1.7.0.0/repos/el/7/puppet5/x86_64/pdk-1.7.0.0-1.el7.x86_64.rpm',
  }

# Install latest PDK directly from Puppet Source
  package {'pdk':
    ensure  => installed,
    source  => '/tmp/pdk.rpm',
    require => File['/tmp/pdk.rpm'],
  }

}

We can then add these changes and push them back up to our remote repository. Our Jenkins scan will then pick up these changes within a minute and give us the all clear. Once we're happy with these results, you can merge your code with a pull request back at the remote repository, and watch this test run again on our master branch.

Now that we have some basic validation in place, we can start building some basic test coverage to rely on our profiles not losing features over time, or regressing.