I have a Java project, building with Gradle, using the Jenkins CI server, and I would like to publish to an Artifactory server, using Maven-compatible artifacts. The project is using Git. I would also like to use the release management features of Jenkins if possible.
This is very confusing. There are at least five plugins, with much overlapping redundant functionality. Some plugins seem to replace others. Some plugins seem to require others.
FYI, the five relevant plugins seem to be:
1) Jenkins Artifactory Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin
2) Gradle "maven" Plugin
http://www.gradle.org/docs/current/userguide/maven_plugin.html
3) Gradle "maven-publish" Plugin
http://www.gradle.org/docs/current/userguide/publishing_maven.html
4) Gradle "artifactory" Plugin
https://www.jfrog.com/confluence/display/RTF/Gradle+Artifactory+Plugin
5) Gradle "artifactory-publish" Plugin
http://www.jfrog.com/confluence/display/RTF/Gradle+1.6+Publishing+Artifactory+Plugin
What is the best way to set this up?
If I use the Jenkins Artifactory Plugin with none of the other plugins mentioned, I get an error:
No publish configurations specified for project ':' and the default 'archives' configuration does not exist.
Cannot publish pom for project ':my-great-app' since it does not contain the Maven plugin install task and task ':my-great-app:artifactoryPublish' does not specify a custom pom path.
I assume I need to use either maven or maven-publish in build.gradle?
maven-publish is labeled as the incubating successor to the maven plugin. How much better is it? How stable is it?
How does using one of the Gradle Artifactory plugins compare to the standard maven publishing plugins vs using the Jenkins plugin?
Gradle Artifactory plugins: Gradle can deploy build artifacts and build information directly, without need in CI server by using one of the Artifactory plugins.
artifactory plugin works with maven plugin and publishes configurations, generated by maven plugin.
artifactory-publish plugin works with maven-publish plugin and publishes publications generated by maven-publish plugin.
Jenkins Artifactory plugin works in two modes:
Providing a UI to override settings, specified in artifactory or artifactory-publish plugins in Gradle build script.
Adding and configuring artifactory plugin to the Gradle script if it is not there.
It also provides release management (for both modes).
So, here's what you need to decide:
Whether you use one of the Gradle plugins. Our recommendation is - use it (versioned configuration in build script is an advantage comparing to UI-only configuration.
Which plugin you want to use -- maven or maven-publish. While the later is still 'incubating', it is much more flexible than the former. Once you know with which maven plugin you want to use, select the appropriate artifactory plugin.
You need the Artifactory Jenkins plugin in either way if you want to use the release functionality, just check (or uncheck) the 'Project uses the Artifactory Gradle Plugin' checkbox.
Related
I would like to set up a Maven repository with Artifactory.
What are the steps to setup Maven plugins repo in Artifactory. I have to load Maven Jacoco plugin from Artifactory local repo.
Seems your use case can be achieved with general instructions of Maven Repository of Artifactory. Since, you would like to deploy maven type package/plugins, there would no difference in the setup.
We should be able resolve the deployed packages/plugins from maven clients without any issues. Is there anything difference in the use case?
Currently I am using JFrog OSS version 5.5.2 for my artifacts which is integrated with Jenkins version 2.19.4. The artifactory plugin version is 2.13.1. I created a free-style software project. The repository type is “generic-local”. I am able to run build successfully and builds are saved in repository but the artifacts are not saved.Also, there is no option called “deploy artifacts to artifactory” in Jenkins configuration.
Do I have change my settings or update Jenkins?
Please advice me what changes has to be done.
Do I need to upgrade jenkins?
No: the Artifactory plugin requires a Jenkins Core 1.521.
But you would need to define a Maven 2/3 build instead.
Maven 3 Support for Jenkins Free-style Jobs
The Jenkins Artifactory plugin supports running Maven 3 builds from free-style jobs by using a Maven 3 build step + a build environment section for the Artifactory Maven 3 integration (artifact and build information deployment).
For Maven 3 builds users are encouraged to configure the Artifactory integration using Jenkins' native Maven 2/3 build projects.
As per the recent announcement on Gradle forum, the Sonar Plugin and Sonar Runner Plugin are being deprecated in favor of the SonarQube plugin. Can someone share any links (documentation or blogs) that demonstrate setting this up in Jenkins. I tried this on the local setup and gradle sonarqube task works great.
Should we continue to use the "Invoke Standalone Sonar Analysis" (from Jenkins-Sonar plugin) build step in a freestyle Jenkins job? With the default settings, it doesn't infer mandatory information like sonar.projectKey, sonar.projectName, sonar.projectVersion, sonar.sources from the build.gradle file. To provide it manually for a multi-module project is painful (particularly for sonar.libraries and sonar.binaries). One could think to generate a sonar-project.properties file as part of a custom gradle task that will subsequently be used by the Standalone Sonar analysis step.
However, it seems that this a generic requirement and I feel that there might be a simpler way out in in the Jenkins-Sonar plugin. Could someone familiar with the Jenkins-Sonar Plugin shed some light on it?
System info:
Gradle 2.5
Jenkins 1.560
SonarQube 4.5
SonarQube Gradle Plugin 1.0
Sonar Runner 2.3
Jenkins Sonar Plugin 2.2
JDK 1.8
Linux 2.6
Thanks in advance!
EDIT:
I did not want to put the database username and password of the remote sonarqube instance in my gradle build file and hence don't want to use the existing 'sonarqube' task.
I think that you are referring to the following improvement that we want to do on the Jenkins SonarQube plugin: SONARJNKNS-217
This should come sooner or later. In the meantime, you're right, there's no easier way than what you described - unfortunately.
I have a non maven project whose binaries get deployed to Nexus.
I used gradle's maven plugin to create the artifacts and publish it to Nexus
Now, the trouble is how do I promote this artifacts to release in Nexus? I tried looking up the M2 release plugin for jenkins but it looks for the pom file in my source code.
There are a number of Gradle examples including usage with the Nexus staging suite in the Nexus book examples and eval guide.
I am using Maven as a build tool and Jenkins as a CI tool. Currently I have a Jenkins job configured with a Maven build step.
I started using SonarQube and was wondering what is the advantage of using the Jenkins SonarQube plugin and configuring the SonarQube analysis as a post-build-action over simply adding sonar:sonar to the goals of my existing Maven build step.
Thanks and best regards,
Ronald
You can save a lot of configuration. So, if you use jenkins sonar plugin you can centralize database credentials and sonar credentials but if you make a decision about execute sonar:sonar in each jenkins job you will configure each with the same credentials.
I just found: Why use sonar plugin for Jenkins rather than simply use maven goal "sonar:sonar"?
And to add one reason: Using the Jenkins SonarQube plugins one can specify "Skip if triggered by SCM Changes". This is nice if you trigger your Jenkins job for each commit but only want to do a SonarQube analysis at a scheduled time, e.g. one per night.
And here is a summary of the the points made by "emelendez":
Centralize database credentials and sonar credentials Use jenkins
Use jenkins sonar plugin configuring SonarRunner for non Java projects
I've just changed to maven-sonar-plugin from the Jenkins SonarQube plugin to avoid divergence of information between the pom.xml and sonar-project.properties.
For example, developers elsewhere had bumped the project version number in the pom.xml, but they don't use the Jenkins builds and didn't care about the sonar-project.properties (or probably understand it). By switching to the maven plugin instead, the project version is defined once and referenced in the sonar property set within the pom.
The downside is that I no longer have the SonarQube link from the project's Jenkins page.
I'm not sure where the responsibility might be for adding this link back for projects using maven-sonar-plugin... The link is "owned" by the Jenkins SonarQube Plugin, but this is not being used here. Meanwhile the maven-sonar-plugin component is integrating with maven not Jenkins.
Something would need to observe the build and extract the SonarQube link which is emitted as a [INFO] ANALYSIS SUCCESSFUL, you can browse http://... line in the log.