Home » DevOps » Field Notes from an Ad-Hoc Jenkins Pipeline

About Ashley Frieze

Ashley Frieze
Software developer, stand-up comedian, musician, writer, jolly big cheer-monkey, skeptical thinker, Doctor Who fan, lover of fine sounds

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!

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
// 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: 'https://github.com/ashleyfrieze/amazon-sqs-java-extended-client-lib'
            }
        }
        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'
                    descriptor.transform()
                }
            }
        }
        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 = rtMaven.run (
                        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.

Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: Field Notes from an Ad-Hoc Jenkins Pipeline

Opinions expressed by Java Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of