I'm puzzled why Gradle's uploadArchive is uploading artifacts from other configurations. My understanding is that when you declare a configuration it will get an upload task for you and when called it will upload the artifacts assigned to its configuration.
That's not the behavior I'm seeing:
apply plugin: 'base'
configurations {
foo
}
task fooIt(type: Zip) {
from 'blah.txt'
baseName 'foo'
}
task barIt(type: Zip) {
from 'blah.txt'
baseName 'bar'
}
artifacts {
foo fooIt
}
repositories {
flatDir {
name 'local'
dirs 'repo'
}
}
uploadArchives {
repositories {
add project.repositories.local
}
}
uploadFoo {
repositories {
add project.repositories.local
}
}
In this example there are no artifacts assigned to the archives configuration but when I call gradle uploadArchives it will upload foo's artifacts.
$ gradle -i uploadArchives
All projects evaluated.
Selected primary task 'uploadArchives' from project :
Tasks to be executed: [task ':fooIt', task ':uploadArchives']
:fooIt (Thread[Daemon Thread 17,5,main]) started.
:fooIt
Skipping task ':fooIt' as it is up-to-date (took 0.008 secs).
:fooIt UP-TO-DATE
:fooIt (Thread[Daemon Thread 17,5,main]) completed. Took 0.017 secs.
:uploadArchives (Thread[Daemon Thread 17,5,main]) started.
:uploadArchives
Executing task ':uploadArchives' (up-to-date check took 0.0 secs) due to:
Task has not declared any outputs.
Publishing configuration: configuration ':archives'
Publishing to Repository 'local'
Published :gradle:unspecified:foo.zip to file:/private/tmp/gradle/repo/foo-unspecified.zip
Published :gradle:unspecified:ivy.xml to file:/private/tmp/gradle/repo/ivy-unspecified.xml
:uploadArchives (Thread[Daemon Thread 17,5,main]) completed. Took 0.017 secs.
BUILD SUCCESSFUL
Two questions out of this:
Why is fooIt getting executed?
Why is uploadArchives uploading foo's artifacts?
Thanks
$ gradle --version
------------------------------------------------------------
Gradle 2.1
------------------------------------------------------------
Build time: 2014-09-08 10:40:39 UTC
Build number: none
Revision: e6cf70745ac11fa943e19294d19a2c527a669a53
Groovy: 2.3.6
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM: 1.7.0_45 (Oracle Corporation 24.45-b08)
OS: Mac OS X 10.10.2 x86_64
The archives configuration contains all artifacts from all configurations. I believe the confusion comes from the fact that you can also add artifacts directly to the archives configuration if you want. That being the case, the uploadArchives task will always upload all the declared artifacts. If you want to upload a subset of your artifacts then you should call the upload<<ConfigurationName>> task.
Related
I'm struggling with deploying the war file to Nexus repository using Jenkinsfile via Gradle task.
The war is being created successfully. I have also no problem with deploying JARs (since there are examples everywhere how to do it).
So I have this publishing section in my build.grade:
publishing {
repositories {
maven {
URI releasesUrl = new URI("${UploadURL}/repository/releases")
URI snapshotsUrl = new URI("${UploadURL}/repository/snapshots")
afterEvaluate {
url version.endsWith("SNAPSHOT") ? snapshotsUrl : releasesUrl
}
credentials {
username "${user}"
password "${password}"
}
}
}
publications {
mavenWeb(MavenPublication) {
from components.web
artifact war.archivePath
}
}
}
With pluggins:
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'maven-publish'
apply plugin: 'org.springframework.boot'
apply plugin: 'war'
The URL for repositories is also specified in the build script correctly (test publish with the jar works just fine)
And the Jenkinsfile:
stage ('Publish war') {
steps {
sh "sh gradlew publish"
}
}
Currently I'm getting this error from jenkins build:
Task :publishMavenWebPublicationToMavenRepository FAILED
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':publishMavenWebPublicationToMavenRepository'.
Failed to publish publication 'mavenWeb' to repository 'maven'
Invalid publication 'mavenWeb': multiple artifacts with the identical extension and classifier ('war', 'null').
I'm quite sure that the problem is within "publications" part of Gradle task.
For publishing the Jars I have been using it like this:
[...]
publications {
mavenJava(MavenPublication) {
from components.java
artifact sourceJar
}
}
[...]
task sourceJar(type: Jar) {
classifier 'sources'
from sourceSets.main.java
}
I do not know how to configure from, artifact and classifier for this task. I do not even know if all of these parameters should be configured... Could anyone help me with that?
It turned out, that the origin of the problem was this section:
afterEvaluate {
url version.endsWith("SNAPSHOT") ? snapshotsUrl : releasesUrl
}
This feature works with Gradle 5.X version however, I was using Gradle 4.8. That lead to null instead of propper url value...
Unfortunately, it took a while since the exception message does not suggest where the problem was.
There is a similar issue here but with no answers and no progress in solving it.
I am running Selenium tests with Cucumber and with Gradle as the build tool. In Jenkins.
This is my build.gradle file:
task cucumber() {
dependsOn assemble, compileTestJava
doLast{
javaexec {
main = "cucumber.api.cli.Main"
classpath = configurations.cucumberRuntime + sourceSets.main.output + sourceSets.test.output
args = ['--plugin', 'pretty', '--glue', 'stepmethods', 'src/main/java/features', '--tags', 'not #proba and not #test and not #rucno and not #nedovrseno']
}
}
}
I wanted to exclude some scenarios from the feature I am testing so I added the '--tags', 'not #proba and not #test and not #rucno and not #nedovrseno' part to Gradle task arguments.
After that (and I'm not 100% sure this is the cause) tests run fine in a Jenkins job, but the reports with Cucumber reports plugin are not getting generated.
Instead, this is the Jenkins console output:
15:09:02 BUILD SUCCESSFUL in 1m 58s
15:09:02 3 actionable tasks: 3 executed
15:09:02 Build step 'Invoke Gradle script' changed build result to SUCCESS
15:09:02 [CucumberReport] Using Cucumber Reports version 4.6.0
15:09:02 [CucumberReport] JSON report directory is ""
15:09:02 [CucumberReport] Copied 1 json files from workspace "C:\Users\me\.jenkins\workspace\Project Name" to reports directory "C:\Users\me\.jenkins\jobs\Project Name\builds\12\cucumber-html-reports\.cache"
15:09:02 [CucumberReport] Copied 4 properties files from workspace "C:\Users\me\.jenkins\workspace\Project Name" to reports directory "C:\Users\me\.jenkins\jobs\Project Name\builds\12\cucumber-html-reports\.cache"
15:09:02 [CucumberReport] Processing 1 json files:
15:09:02 [CucumberReport] C:\Users\me\.jenkins\jobs\Project Name\builds\12\cucumber-html-reports\.cache\report.json
15:09:02 [CucumberReport] Missing report result - report was not successfully completed
15:09:02 [CucumberReport] Build status is left unchanged
15:09:02 Finished: SUCCESS
So, the files are processed, but the report is missing. What could be the problem?
EDIT
Added second '--plugin' to string to account for the OP's finding.
Removed additional examples.
Try
task cucumber() {
dependsOn assemble, compileTestJava
doLast{
javaexec {
main = "cucumber.api.cli.Main"
classpath = configurations.cucumberRuntime + sourceSets.main.output + sourceSets.test.output
args = ['--plugin', 'pretty', '--plugin', 'html:some/dir', '--glue', 'stepmethods', 'src/main/java/features', '--tags', 'not #proba and not #test and not #rucno and not #nedovrseno']
}
}
}
You didn't specify which report you wanted nor where you wanted it generated. This gives you pretty and html.
I try to run sonar tests with maven in my Jenkins pipeline project. The documentations says if the sonar is configured globally and you use the withSonarQube step the environment variables with the globally configured sonar properites are injected. So far so good.
http://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Jenkins#AnalyzingwithSonarQubeScannerforJenkins-AnalyzingwithSonarQubeScannerforMaven
My pipeline config looks like:
def stash = '********'
def branch = 'dev'
stage('git') {
node {
git branch: branch, credentialsId: 'Buildserver-Private.key', url: stash
}
}
stage('build') {
node {
//....
}
}
stage('sonar') {
node {
withSonarQubeEnv('Sonar') {
sh 'mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar'
}
}
}
The build fails because the sonar plugin trys to connect to the default h2 database instead of the configured one. If i check the log, there are no sonar properties passed to maven.
Injecting SonarQube environment variables using the configuration: Sonar
[Pipeline] {
[Pipeline] tool
[Pipeline] sh
[***********] Running shell script
+ cd .
+ /var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3_3_9/bin/mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar
[INFO] Scanning for projects...
[...]
[INFO] --- sonar-maven-plugin:3.2:sonar (default-cli) # *******.project.build ---
[INFO] User cache: /var/lib/jenkins/.sonar/cache
[INFO] SonarQube version: 4.5.6
[INFO] Default locale: "en_US", source code encoding: "UTF-8" (analysis is platform dependent)
12:23:17.971 INFO - Load global referentials...
12:23:18.071 INFO - Load global referentials done: 102 ms
12:23:18.102 INFO - User cache: /var/lib/jenkins/.sonar/cache
12:23:18.109 INFO - Install plugins
12:23:18.176 INFO - Install JDBC driver
12:23:18.183 INFO - Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
Why is my config ignored? What does the documentation mean if it says?
Since version 2.5 of the SonarQube Scanner for Jenkins, there is an
official support of Jenkins pipeline. We provide a 'withSonarQubeEnv'
block that allow to select the SonarQube server you want to interact
with. Connection details you have configured in Jenkins global
configuration will be automatically passed to the scanner.
It seems they are not ...
Has anybody an idea what am I missing?
You are using an old version of SonarQube (4.5.6, the previous LTS) that requires to pass DB connection parameters (URL, login, password) to the scanners - which is a security issue. withSonarQubeEnv does not propagate those settings in order to fix this flaw.
Since SonarQube 5.2, these parameters are no longer required. So you have to use a version that is more recent. I suggest you to upgrade to the latest LTS version of SonarQube (5.6).
I have a new Grails 3.1.7 project compiled by gradle wrapper. The project is just the base project created by: grails create-app
When I run:
./gradlew --info clean jar bootRepackage
I see the following output during the last part of the build
:jar (Thread[main,5,main]) started.
:jar
Executing task ':jar' (up-to-date check took 0.023 secs) due to:
Output file /var/jenkins_home/workspace/helloworld/build/libs/helloworld-0.1.jar has changed.
Output file /var/jenkins_home/workspace/helloworld/build/libs/helloworld-0.1.jar has been removed.
:jar (Thread[main,5,main]) completed. Took 0.259 secs.
:findMainClass (Thread[main,5,main]) started.
:findMainClass
Executing task ':findMainClass' (up-to-date check took 0.0 secs) due to:
Task has not declared any outputs.
:findMainClass (Thread[main,5,main]) completed. Took 0.041 secs.
:war (Thread[main,5,main]) started.
:war
Executing task ':war' (up-to-date check took 0.039 secs) due to:
Output file /var/jenkins_home/workspace/helloworld/build/libs/helloworld-0.1.war has changed.
Output file /var/jenkins_home/workspace/helloworld/build/libs/helloworld-0.1.war has been removed.
:war (Thread[main,5,main]) completed. Took 4.305 secs.
:bootRepackage (Thread[main,5,main]) started.
:bootRepackage
Executing task ':bootRepackage' (up-to-date check took 0.0 secs) due to:
Task has not declared any outputs.
Jar task not repackaged (didn't match withJarTask): task ':jar'
Jar task not repackaged (didn't match withJarTask): task ':pathingJar'
Jar task not repackaged (didn't match withJarTask): task ':pathingJarCommand'
Setting mainClass: helloworld.Application
:bootRepackage (Thread[main,5,main]) completed. Took 0.94 secs.
BUILD SUCCESSFUL
What is happening in the repackage task?
What does this mean?
Jar task not repackaged (didn't match withJarTask): task ':jar'
gradle.properties:
grailsVersion=3.1.7
gradleWrapperVersion=2.13
build.gradle:
buildscript {
ext {
grailsVersion = project.grailsVersion
}
repositories {
mavenLocal()
maven { url "https://repo.grails.org/grails/core" }
}
dependencies {
classpath "org.grails:grails-gradle-plugin:$grailsVersion"
classpath "com.bertramlabs.plugins:asset-pipeline-gradle:2.8.2"
classpath "org.grails.plugins:hibernate4:5.0.6"
}
}
version "0.1"
group "helloworld"
apply plugin:"eclipse"
apply plugin:"idea"
apply plugin:"war"
apply plugin:"org.grails.grails-web"
apply plugin:"org.grails.grails-gsp"
apply plugin:"asset-pipeline"
ext {
grailsVersion = project.grailsVersion
gradleWrapperVersion = project.gradleWrapperVersion
}
repositories {
mavenLocal()
maven { url "https://repo.grails.org/grails/core" }
}
dependencyManagement {
imports {
mavenBom "org.grails:grails-bom:$grailsVersion"
}
applyMavenExclusions false
}
dependencies {
compile "org.springframework.boot:spring-boot-starter-logging"
compile "org.springframework.boot:spring-boot-autoconfigure"
compile "org.grails:grails-core"
compile "org.springframework.boot:spring-boot-starter-actuator"
compile "org.springframework.boot:spring-boot-starter-tomcat"
compile "org.grails:grails-dependencies"
compile "org.grails:grails-web-boot"
compile "org.grails.plugins:cache"
compile "org.grails.plugins:scaffolding"
compile "org.grails.plugins:hibernate4"
compile "org.hibernate:hibernate-ehcache"
console "org.grails:grails-console"
profile "org.grails.profiles:web:3.1.7"
runtime "com.bertramlabs.plugins:asset-pipeline-grails:2.8.2"
runtime "com.h2database:h2"
testCompile "org.grails:grails-plugin-testing"
testCompile "org.grails.plugins:geb"
testRuntime "org.seleniumhq.selenium:selenium-htmlunit-driver:2.47.1"
testRuntime "net.sourceforge.htmlunit:htmlunit:2.18"
}
task wrapper(type: Wrapper) {
gradleVersion = gradleWrapperVersion
}
assets {
minifyJs = true
minifyCss = true
}
The code for this example is at: https://github.com/liftyourgame/helloworld
prior to grails-3.1.5, the bootRepackage task has processed all jar tasks which was undesired for pathing jars.
now it processes only the war task if the War plugin is applied (by default).
also, a gradle(w) assemble (which is also used by grails war, for example) builds only a war (no jar) artefact if the War plugin is applied. the same applies to spring-boot.
but that is usually just fine because the war is also executable (i.e. java -jar my.war).
so if you really want to build that jar artefact and that should be subject to repackaging, reconfigure the bootRepackage task accordingly:
bootRepackage.withJarTask = jar
however - if there is no good reason against it - i would say its better to stick to the war file and use that as executable. or remove the War plugin which makes assemble and bootRepackage default to build/process the jar artefact.
How can I call the Ant target 'jar' from the Gradle build file? I've tried a number of things to no avail. Renaming the 'jar' target in the Ant build file is not an option. I'm in the process of converting an Ant based build system to Gradle and the first required step is to call all the Ant targets from Gradle.
The 'jar' task is a default Gradle task so I'm overwriting/overriding it but I need to call my similarly named Ant target.
Gradle build.gradle file:
// Prevents error "Cannot add task {taskname} as a task with that name already exists"
ant.project.addTarget('clean', new org.apache.tools.ant.Target())
ant.project.addTarget('jar', new org.apache.tools.ant.Target())
ant.project.addTarget('test', new org.apache.tools.ant.Target())
ant.project.addTarget('javadoc', new org.apache.tools.ant.Target())
ant.importBuild 'build.xml'
task jar(overwrite: true) {
println 'jar'
}
task clean(overwrite: true) {
println 'clean'
}
task test(overwrite: true) {
println 'test'
}
and my Ant build.xml:
<target name='jar' description='jar'>
<echo>Called jar task in ant build</echo>
</target>
Running Gradle v1.2
------------------------------------------------------------
Gradle 1.2
------------------------------------------------------------
Gradle build time: Wednesday, September 12, 2012 10:46:02 AM UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ivy: 2.2.0
JVM: 1.6.0_25 (Sun Microsystems Inc. 20.0-b11)
OS: Linux 2.6.37.6 amd64
Gradle only adds a jar task when you apply the Java plugin, which you shouldn't do for the project into which you import the Ant build. I don't think you should ever call ant.project.addTarget from a Gradle build script.