Managing Nexus API Using Jenkins X

In my last post, Jenkins X — Managing Jenkins, I talked about how we manage our Jenkins server. This time around, I’ll be looking at the Nexus server and how it too can be similarly managed.

Current Status

Jenkins X comes with an optional Nexus server packaged into the platform which is great to get you started. However, as your project becomes more complex, you might find yourself needing other repositories or changes to the configuration. It is these changes which proved a little difficult to manage. Here is the setup as of today:

• current Jenkins X nexus chart hard-codes the pre-packaged repositories
• the postStart.sh script takes the list of repository script files and executes them
• there is an open issue on GitHub to move the files into the values.yaml but I’m not sure when it will be fixed.

So, that being the case, we need a way to add our custom repositories. Now before I get into the implementation, I’d like to give you a little background as to what is actually happening.

The postStart.sh Script

The postStart.sh script runs directly after the Nexus server becomes available. Its job, among other things, is to loop over a list of files containing repository creation scripts and to execute them in Nexus. The scripts themselves are idempotent meaning the Nexus repository will only be created if it does not already exist. This ensures that your Nexus server will have all the necessary repositories on startup.

Sponsorships Available

Sponsorships Available

Sponsorships Available

So, how do the scripts work?

The Nexus API

Sonatype Nexus uses groovy scripts to configure the instance. Out of the scope of this post, here is a great example of configuring Nexus through scripts.

Here is some more information from the official Nexus site:

• https://help.sonatype.com/repomanager3/rest-and-integration-api/script-api/examples
• https://github.com/sonatype-nexus-community/nexus-scripting-examples

And? (Read more...)