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 plugindef 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', } } 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. |
