Skip to main content

Automatically sending artifacts from Jenkins to a repository manager: the quickest (and not so dirty) way

In order to store artifacts in a repository at the end of a successful build some plugins are available in the Jenkins update centre. The configuration of these plugins is sometimes tricky, the documentation poor or not updated and some of them are tested (and work) only against one of the available Open Source and commercial build artifact repository managers and fail against others. A quick and not so dirty general way to complete this action is described in this post. This solution works fine against Apache Archiva, but it should work fine with Artifactory or Nexus as well.
You need to add a Invoke top-level Maven target as latest build step for the build job you're running to build your Java application/library and configure it the following way:

Maven version: any Maven version you need (you can use the default for your Jenkins instance or one among the different releases that you may have set up for it).
Goals: deploy:deploy-file -Dfile=<application_root>\target\<artifact_name>.jar -DpomFile=<application_root>\pom.xml -DrepositoryId=<artifact_repository_id> -Durl=<artifact_repository_url>
where
  • application_root is the root of the Java application/library in the build job workspace
  • artifact_name is the choosen name for the artifact
  • artifact_repository_id is the ID of the Archiva repository inside the Maven settings.xml file to use (let's go back on this later in this post)
  •  artifact_repository_url is the HTTP URL of the destination Archiva repository. 
Use private Maven repository: checked
Settings file: Settings file in filesystem and the path to the settings.xml to use
Global Settings file: Settings file in filesystem and the path to the settings.xml file to use

The settings file could belong to a different Maven installation but accessible by Jenkins. If authentication is required to access the Archiva repository the settings file to use should contain the authentication credentials. You need to add a new <server> tag to the list of servers (<servers> tag):

<servers>
...
<server>
        <id>repoId</id>
        <username>username</username>
        <password>password</password>
</server>
 ...
</servers>

repoId is the id to be used as value for the repositoryId argument of the deploy-file Maven goal.
Finally, in order to skip the deploy of the artifact just in case one of the previous build steps (build, unit tests, code coverage, static analysis, whatever) should fail you should add a conditional step (you need the Conditional Build Step plugin (https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin) for this) as well. The following snapshots show the final configuration:






Labels:

Comments

Post a Comment

Popular posts from this blog

Turning Python Scripts into Working Web Apps Quickly with Streamlit

 I just realized that I am using Streamlit since almost one year now, posted about in Twitter or LinkedIn several times, but never wrote a blog post about it before. Communication in Data Science and Machine Learning is the key. Being able to showcase work in progress and share results with the business makes the difference. Verbal and non-verbal communication skills are important. Having some tool that could support you in this kind of conversation with a mixed audience that couldn't have a technical background or would like to hear in terms of results and business value would be of great help. I found that Streamlit fits well this scenario. Streamlit is an Open Source (Apache License 2.0) Python framework that turns data or ML scripts into shareable web apps in minutes (no kidding). Python only: no front‑end experience required. To start with Streamlit, just install it through pip (it is available in Anaconda too): pip install streamlit and you are ready to execute the working de...
12 comments
Read more

jOOQ: code generation in Eclipse

jOOQ allows code generation from a database schema through ANT tasks, Maven and shell command tools. But if you're working with Eclipse it's easier to create a new Run Configuration to perform this operation. First of all you have to write the usual XML configuration file for the code generation starting from the database: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <configuration xmlns="http://www.jooq.org/xsd/jooq-codegen-2.0.4.xsd">   <jdbc>     <driver>oracle.jdbc.driver.OracleDriver</driver>     <url>jdbc:oracle:thin:@dbhost:1700:DBSID</url>     <user>DB_FTRS</user>     <password>password</password>   </jdbc>   <generator>     <name>org.jooq.util.DefaultGenerator</name>     <database>       <name>org.jooq.util.oracle.OracleDatabase</name>     ...
3 comments
Read more

Load testing MongoDB using JMeter

Apache JMeter ( http://jmeter.apache.org/ ) added support for MongoDB since its 2.10 release. In this post I am referring to the latest JMeter release (2.13). A preliminary JMeter setup is needed before starting your first test plan for MongoDB. It uses Groovy as scripting reference language, so Groovy needs to be set up for our favorite load testing tool. Follow these steps to complete the set up: Download Groovy from the official website ( http://www.groovy-lang.org/download.html ). In this post I am referring to the Groovy release 2.4.4, but using later versions is fine. Copy the groovy-all-2.4.4.jar to the $JMETER_HOME/lib folder. Restart JMeter if it was running while adding the Groovy JAR file. Now you can start creating a test plan for MongoDB load testing. From the UI select the MongoDB template ( File -> Templates... ). The new test plan has a MongoDB Source Config element. Here you have to setup the connection details for the database to be tested: The Threa...
39 comments
Read more