Field Notes from an Ad-Hoc Jenkins Pipeline

I recently had a challenge. I have written a PR to improve an open source library, but the owners of that library haven’t merged it. I don’t really want to wait until they merge the library until I can use it, so I need to deploy my copy of it, with a modified version ID, to a private artifactory server.

The fact that I can’t modify the repo to have a Jenkinsfile and the fact that what I’m trying to do, in terms of building with my own ad-hoc version, requires some careful scripting. The solution is to use an ad-hoc bit of pipeline as a pure pipeline build in Jenkins.

The fact that you can write an arbitrary powerful script like this and just run it in a Jenkins box is proof enough that you should keep them secure!

// define the server instance via it's name and
// the artifactory plugin
def server = Artifactory.server "artifactory_prod"
server.credentialsId = 'artifactory-apitoken'

pipeline {
    environment {
        buildInfo = null
    agent any
    stages {
        // A pure pipeline build needs to be told how to check out
        stage ('Checkout') {
            steps {
                // the feature branch I hope be merged to an official release
                // and the link to my github repo
                git branch: 'batch_uses_s3',
                    url: ''
        stage ('Rewrite version') {
            steps {
                script {
                    // the version of the pom file from git is not under our control
                    // so modify it to disambiguate from the _real_ version
                    def descriptor = Artifactory.mavenDescriptor()
                    descriptor.version = '1.0.2f'
        stage ('Build') {
            steps {
                script {
                    def rtMaven = Artifactory.newMavenBuild()
                    // Set Maven build tool
                    rtMaven.tool = 'maven-3-6-1'

                    // the artifactory virtual repos for resolving
                    // dependencies
                    rtMaven.resolver (
                        server: server,
                        releaseRepo: 'libs-release',
                        snapshotRepo: 'libs-snapshot'

                    // the run command in a moment is going to build
                    // then deploy - we need to set the target server
                    // and repo to use
                    rtMaven.deployer (
                        server: server,
                        releaseRepo: 'internal-release'
                    // do the build - though this doesn't include deploy
                    // the artifactory plugin will do the deploy for us
                    buildInfo = (
                        pom: 'pom.xml',
                        goals: 'clean install',
                junit 'target/surefire-reports/*.xml'

Some copyable tidbits in there… but here’s the thing. This is not a great way to use maven. It seems like the authors of artifactory have become somewhat overwhelmed by their own product and think it’s the centre of a build… and that’s odd.

To have to give the execution of maven over to artifactory to run for you, makes little sense. It’s kind of helping here as it’s overriding the lack of our local artifactory in the pom file of this particular repo’s maven build, but it’s a funny way around. Maven allows you to control its use of an artifactory via either the pom or the command line. To do this via the plugin seems to be tight coupling, and I’m pretty sure it gives you fewer options for configuring things, rather than more.

It does, however, save you knowing how to set the right values in the maven command line.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s