Jenkins built a parameterization with a selection of versions of the Nexus artifact (all GAV)

Question

Is there a Jenkins plugin that can search the artifact version (GAV) group of my Nexus repository and display the results? I would like the results to be available in a parameterized assembly as a choice (drop down list).

Answer 1

I added a groovy script to the dynamic selection parameter (see Jenkins Plugins )

Some of the obstacles were as follows:

• Our Nexus server issues the main authentication task, so I couldn’t just use groovy " http: // blah " .toURL (). Text
• I didn’t want to load jars into missing groovy, such as httpbuilder, so I just used the Java URLConnection class and the encoded user: pass as header.
• Used REST api for Nexus to get versions, but had to distinguish between release and snapshots. I added group authentication so that only developers have access to snapshots.
• GAV variety is not direct. There is a better way to sort GAV (using org.apache.maven.artifact.versioning.ComparableVersion ), but I haven't implemented it yet, so for now I just sort, so smaller lines are built first.

import hudson.model.* import jenkins.model.* def versions=[ ] def snapshots=[ ] // The artifactName could be passed in from another parameter (eg. Extended Choice Parameter) linked to this 'dynamic choice' parameter. def address = "https://xyzcompany.com/nexus/service/local/lucene/search?r=releases&g=com.xyzcompany&a=artifactName&c=features&p=xml" def urlInfo = address.toURL() // Consider using tokenstring technique instead of basic auth if pro version of Nexus. def authString = "user:pass"; // replace 'user' with username, 'pass' with password. def authStr="Basic " + authString.bytes.encodeBase64().toString() // Using URLConnection instead of HTTPBuilder et al. def connection = urlInfo.openConnection() connection.setRequestProperty( "Authorization" , authStr) def xml="${connection.content.text}" def root = new XmlParser().parseText( xml ) root.data.artifact.each { if (it.artifactHits.artifactHit.repositoryId.text() == "releases") versions.add("${it.version.text()}"); else snapshots.add("${it.version.text()}"); } // There is a better way to GAV sort (using org.apache.maven.artifact.versioning.ComparableVersion) but I have not implemented it yet so for now, I'm simply sorting so the smaller strings line up first. versions.sort { -it.size() } Collections.reverse(versions) // Only certain users should be able to see the SNAPSHOT versions def userid = User.current().id def auths = Jenkins.instance.securityRealm.loadUserByUsername(userid).authorities.collect{a -> a.authority} if (["OffShoreDevGroup", "DevGroup"].intersect(auths)) { snapshots.sort { -it.size() } Collections.reverse(snapshots) versions+=snapshots } versions.add(" "); // My build uses a blank version string to simply report what is already deployed to the container. return versions; 

Answer 2

No need to create your own Ruby scripts. Now there is a special plugin that does what you need: Maven metadata plugin for Jenkins CI server

Just mark "Parameterized Build" and "Add Parameter" of type "List of artifact versions of Maven":

• Name MY_SNAPSHOT_JAR
• Repository base URL (this complicated process) http://localhost/nexus/service/local/repositories/snapshots/content

Then add the shell command to wget / scp / etc, you can use the following variables allowed by the plugin:

 wget "$MY_SNAPSHOT_JAR_ARTIFACT_URL" echo "$MY_SNAPSHOT_JAR_VERSION" - the version you selected in the dropdown or that was selected as part of an automated build echo "$MY_SNAPSHOT_JAR_ARTIFACT_URL" - the full URL to the actual artifact selected. You can use something like "wget" to download that artifact and do something with it. echo "$MY_SNAPSHOT_JAR_GROUP_ID" - echoes back your configuration echo "$MY_SNAPSHOT_JAR_ARTIFACT_ID" - echoes back your configuration echo "$MY_SNAPSHOT_JAR_CLASSIFIER" - echoes back your configuration echo "$MY_SNAPSHOT_JAR_PACKAGING" - echoes back your configuration 

Unfortunately, you cannot ask about the snapshot and release in the same drop-down list. A possible workaround is to add another parameter for MY_RELEASE_JAR (thus another drop-down list, somewhat confusing for the user). Another workaround is a separate task for deployment deployment.