I have an incredibly basic Gradle build file:
plugins {
id "base"
id "com.jfrog.artifactory" version "4.3.0"
}
configurations {
batchConfig
}
artifacts{
file("dist").eachFile{ zipFile ->
batchConfig zipFile
}
}
println "BatchConfig Artifacts: " + configurations.batchConfig.allArtifacts
This is executed via Jenkins and appears to work fine:
Archives Artifacts: [DefaultPublishArtifact_Decorated
module-0.0.post0.dev6+n4c62094-py2.7:egg:egg:null]
[buildinfo] Properties file found at
'/tmp/buildInfo65481565498521.properties'
:artifactoryPublish
Deploying build descriptor to:
https://ourArtifactoryServer/artifactory/api/build
Build successfully deployed.
Browse it in Artifactory under
https://ourArtifactoryServer/artifactory/webapp/builds/testGradleBuild/34
BUILD SUCCESSFUL
However the artifact is not actually uploaded to Artifactory at all.
SSL cert configuration appears to be working fine, as I had to address that first. Any suggestions as to what I'm missing here?
Looks like you do still need to utilise the artifactory closure outlined in the Gradle Artifactory Plugin. Switching back to using "archives" instead of a custom Config and then adding this to my build sorted it:
artifactory {
publish {
defaults {
publishConfigs('archives')
}
}
}
Related
My question is related to:
Jenkins Declarative Pipeline with custom settings.xml
I would like to use Maven with a custom settings.xml created via the Config File Provider plugin. This works fine when wrapping the Maven calls with withMaven(...) or configFileProvider(...), but as pointed out in this comment, it becomes cumbersome when using e.g. multiple stages.
I wonder if this can be avoided with a one-time setup. For instance:
pipeline {
tools {
maven: 'someMaven'
jdk: 'someJdk'
}
environment {
MVN_SETTINGS = 'somehow get path to settings.xml created via Config File Provider Plugin'
}
stages {
stage('someStage') {
sh "mvn --settings ${MVN_SETTINGS} ..."
}
}
}
Usually we bundle the settings.xml file with the source code.
This is especially helpful when sharing the project, or building it on different workspaces.
Any reason why you dont bundle the settings.xml inside your code repository?
We use Sonatype Nexus as artefact repository, configured with credentials in Jenkins and it works fine.
Now i'm trying to get get a gradle project running as jenkins multibranch pipeline job using gradlew including a sonarqube code scan.
Problem:
when using only the rootProjekt.name property in settings.gradle
i get this error:
What went wrong: Plugin [id: 'org.sonarqube', version: '2.6.2'] was not found in any of the following sources:
Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
Plugin Repositories (could not resolve plugin artifact 'org.sonarqube:org.sonarqube.gradle.plugin:2.6.2') Searched in the
following repositories:
Gradle Central Plugin Repository
The sonarqube gradle plugin is found when using the Nexus web UI, but not by gradle inside the pipeline, seems it searches only in Gradle Central Plugin Repository.
When using a Settings.gradle like that:
pluginManagement {
repositories {
maven {
url "http://nexushost/content/groups/public/"
}
}
}
rootProject.name = 'fooBar'
it works like a charm.
How to tell gradle it should always use the sonatype nexus host without having
to configure it in settings.gradle for every Job ?
You should use a Gradle init script.
For example, in every agent, create a file USER_HOME/.gradle/init.d/use-corporate-nexus.gradle, with content:
settingsEvaluated { settings ->
settings.pluginManagement {
repositories {
maven {
url "http://nexushost/content/groups/public/"
}
}
}
}
For some reason gradle is not downloading dependencies from Maven Central. We have a private Nexus repository set up as well and for some reason gradle is looking there for dependencies and not Maven Central.
I get a ton of errors similar to:
Failed to get resource: HEAD. [HTTP HTTP/1.1 400 Repository version policy: SNAPSHOT does not allow version: 1.5.0.RELEASE: http://*****/repository/******/io/pivotal/spring/cloud/spring-cloud-services-dependencies/1.5.0.RELEASE/spring-cloud-services-dependencies-1.5.0.RELEASE.pom]
I swear I have resolved this before when I first set it up, but cannot replicate. In order for me to hit Maven Central, I must have the proxy set up and have Nexus as an exclusion to the proxy.
This all works locally, but the issue comes in when dealing with Jenkins and the Sonarqube plugin. Locally I've tried various proxy settings (remove systemProps or even system env variables), but errors are not the same (ie cannot find host).
Any idea why it's not able to download from Maven Central?
Update:
So I was able to narrow it down a little further. When using Jenkins and Sonarqube withSonarQubeEnv block, something happens with how gradle resolves dependencies. See 3 examples:
// #1 This breaks when SNAPSHOT is declared first
repositories {
maven { // <------------------ SNAPSHOT
credentials {
username usr
password pass
}
url uri(snapshot)
}
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
mavenCentral() // <---------- Maven Central
}
// #2 This works since mavenCentral() is first:
repositories {
mavenCentral() // <---------- Maven Central
maven { // <------------------ SNAPSHOT
credentials {
username usr
password pass
}
url uri(snapshot)
}
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
}
// #3 This also works because no failing version policy:
repositories {
maven { // <------------------ RELEASE
credentials {
username usr
password pass
}
url uri(release)
}
mavenCentral() // <---------- Maven Central
}
This works fine when not using withSonarQubeEnv in Jenkins. Why would order matter when using withSonarQubeEnv?
Figured it out. It had nothing to do with withSonarQubeEnv block in Jenkins. The Sonarqube sample settings for gradle had the --info flag added, which I was using for testing. I added that to my build step and found same errors. I even cleaned the cache in the .gradle folder and everything still downloaded.
I suppose Gradle does something a little misleading when it tries to resolve dependencies. It spits out info messages when retrieving a RELEASE artifact from a SNAPSHOT repository, but it still continues to retrieve the artifact from the other listed repositories.
I am archiving artifacts at the end of each build. I have https://wiki.jenkins-ci.org/display/JENKINS/Archived+Artifact+Url+Viewer+PlugIn installed.
Thought the plugin says artifacts can be viewed here
"/archivedArtifacts/artifact/job_name/build_number/relative location of zip or jarfile within artifact folder/location of file within archive Ex:
http://jenkins_url/archivedArtifacts/artifact/Build%20-%20Dev/10526/junit-logs.zip/junit.log"
I am unable to see artifacts using this URL
http://localhost:8080/archivedArtifacts/artifact/TestFirstJob/32/target/MavenTest-0.0.1-SNAPSHOT.jar
I do not have any "artifact" folder. I do have archive folder in the inside each build number.
I can see artifacts of the last build on the respective job homepage.
Any help to view artifacts using this URL is appreciated. Also, Is there a way I can view all of the artifacts build so far at one place.
Archive is how to save files outside workspace. We can clean our workspace, run other builds and the file archived is still safe.
For do that is simple, only with one command we can artifact our files.
archiveArtifacts artifacts: 'file.extension'
For example:
pipeline {
agent any
stages {
stage('Download') {
steps {
sh 'echo "artifact file" > generatedFile.txt'
}
}
}
post {
always {
archiveArtifacts artifacts: 'generatedFile.txt', onlyIfSuccessful: true
}
}
}
Once we build the pipeline and it is successfull, we can find our artifact in either of the following locations:
$JENKINS_HOME/yourjobname/branches/branchname/builds/yourbuildernumer/archive
$JENKINS_HOME/yourjobname/builds/yourbuildernumer/archive
I'm using Gradle and Jenkins and want to deploy artifacts to Artifactory. Unfortunately this deployment works only once, when I start the build in Jenkins.
If I delete the workspace and the ~/.gradle Folder on the Jenkins server the deployment works again. Deleting only the workspace alone is not enough.
Seems like a bug for me. Do I have any unknown version conflicts. Or is it something different I don't see. Thanks for any help.
Environment:
Jenkins 2.7.3
Gradle 3.1
Artifactory 4.13.0
Jenkins Artifactory Plugin 2.7.2
Gradle Build Script: (Based on example from jfrog)
buildscript {
repositories {
jcenter()
}
dependencies {
classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '4.4.5')
}
}
allprojects {
apply plugin: 'java'
apply plugin: 'maven-publish'
repositories {
jcenter()
}
group = 'org.jfrog.example.gradle'
version = '1.0.1-SNAPSHOT'
status = 'integration'
}
artifactory {
publish {
defaults {
publishConfigs('archives')
}
}
}
// Setting this property to true will make the artifactoryPublish task
// skip this module (in our case, the root module):
artifactoryPublish.skip = true
Jenkins Artifactory Plugin Settings:
[x] Gradle-Artifactory-Integration
[x] Capture and publish build info
[x] Publish artifacts to Artifactory
[x] Publish Maven Descriptors
[x] Use Maven compatible Patterns
Rest is deactivated (not set).
Log in Jenkins (Console Output), on second run with changed version and changed source code:
Jenkins Artifactory Plugin version: 2.7.2
[Gradle] - Launching build.
[CdExampleArtifactory] $ cmd.exe /C '""C:\Program Files (x86)\Jenkins\tools\gradle-3.1\bin\gradle.bat"' --init-script c:/temp/init-artifactory8368571638486556211gradle artifactoryPublish && exit %%ERRORLEVEL%%"
:artifactoryPublish
:api:artifactoryPublish
:services:artifactoryPublish
:shared:artifactoryPublish
:services:webservice:artifactoryPublish
BUILD SUCCESSFUL
Total time: 2.422 secs
Build step 'Invoke Gradle script' changed build result to SUCCESS
Finished: SUCCESS
It looks like the task don't start the build (jar, etc.) process.
Using the latest Gradle Artifactory Plugin version 4.4.7 solves the compatibility issue with Gradle 3.1.
Gradle build snippet:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '4.4.7')
}
}
Note the version.
I found a solution for my problem.
I have to deactivate the gradle deamon on the jenkins server (via GRADLE_OPTS).