Gradle example

[rpocase]

Desired Behavior

I'd like to have an example implementation using gradle (specifically gradlew) over maven.

Benefits

Gradle is generally much more flexible and easier to consume for users. Maven is much harder to integrate with these days. A major benefit we have seen with gradle is to provide foundational plugins that provide good default config - one benefit of this could be to provide a plugin that specifies the recommended dependencies (e.g. jenkins core version) for a wide set of pipeline libraries.

[matthew-bovolotto]

Agreed. I have spent some time attempting to create a build.gradle file to get this working however I keep running into roadblocks and do not have time to invest on this anymore. I uploaded my example so far if anyone has any time to continue working on it.

https://github.com/matthew-bovolotto/jenkins-spock-gradle

[kamilszymanski]

You can find working examples at https://github.com/kamilszymanski/jenkins-pipeline-automation-starter.
The repository contains jenkins-pipeline-unit based examples in addition to jenkins-spock, but they are kept separate and can be easily removed.
@awittha if you want I can link the repository to the working example section of a README file or in any other suitable place.

[awittha]

@kamilszymanski , thank you! I have not had a chance to look yet, but it's on my radar and I'll let you know when I have.

[awittha]

I took a look! Oh boy, what fun!

https://github.com/homeaway/jenkins-spock/tree/issue-22/examples/shared-library-gradle

Transitive Dependency JARs from Jenkins Plugins

There is a problem that hopefully someone with Gradle experience can help me solve.

The problem is that the default extension for Jenkins plugin dependencies is .hpi, which is basically a Java WAR. Adding a dependency on a Jenkins plugin like so:

testImplementation(
	group: 'org.jenkins-ci.plugins.workflow',
	name: 'workflow-step-api',
	version: '2.21' )

finds the hpi dependency, not the JAR, and the plugin's classes aren't actually available on the classpath.

Explicitly asking for the JAR like so:

testImplementation 'org.jenkins-ci.plugins.workflow:workflow-cps-global-lib:2.10@jar'

does correctly pull the JAR onto the classpath, but this notation causes Gradle to fail to resolve transitive dependencies when used on a Maven artifact. See gradle/gradle#1487

The result is that every last transitive dependency from the whole dependency tree rooted at that Jenkins plugin, must be added to the build.gradle dependencies { ... block, or else there will be various NoClassDefFound exceptions when the JVM tries to actually load the classes.

This form has the same issue:

testImplementation(
	group: 'org.jenkins-ci.plugins.workflow',
	name: 'workflow-step-api',
	version: '2.21',
	ext: 'jar' )

What I Think We Need

Looking at the Gradle hooks for dependency resolution and substitution, I think something like this:

configurations.all {
	resolutionStrategy.eachDependency { DependencyResolveDetails details ->
		if( details.requested.ext == 'hpi' ) {
			details.useExt 'jar'
			details.because 'jenkins-spock needs JAR dependencies for Jenkins plugins, not HPIs'
		}
	}
}

to transform all hpi-resolved artifacts to use the extension jar instead, would solve the problem.

However, neither the DependencyResolveDetails nor the DependencySubstitution classes expose artifact extensions - only group, name, and version. I am not very familiar with Gradle, and am currently stuck here. I was working off of the "Customizing resolution of a dependency directly" Gradle documentation page.

At this time, I must kick the ball back into the open-source community's court and hope someone knows more about this than I. We're very close, though! I did get partial test-runs with that branch, just, once I started having to add a billion dependencies that the Maven/pom.xml-powered tests didn't, I dug and discovered this pretty-fundamental problem.

[rnc]

I found https://discuss.gradle.org/t/converting-from-maven-to-gradle-need-more-specified-dependencies-in-build-gradle-or-tests-fail/18186/4 and https://discuss.gradle.org/t/configuration-and-transitive-dependency-management-by-extension/23824/3 both of which suggest avenues to investigate?

[corporate-gadfly]

At this time, I must kick the ball back into the open-source community's court and hope someone knows more about this than I.

@awittha I don't know much of jenkins-spock or spock or shared libraries, but I do have a need for a testable shared library in gradle (since I'm in the process of creating new shared libraries) for my organization.

Building on the work of @matthew-bovolotto, @kamilszymanski and the work described in #59, I was able to come up with a very minimal gradle project in pull request #67 .

Feedback is most welcome. Hope that helps and hopefully this can lead to a full shared-library-gradle example.

commit 14d008de7333a63ce1dddaa02ce470135aa00a5f (HEAD -> master, origin/master, origin/HEAD)
Date:   Tue Apr 7 13:52:47 2020 -0400

    minimal example for jenkins-spock used from gradle

examples/helper-script-gradle/.gitignore
examples/helper-script-gradle/.keep
examples/helper-script-gradle/build.gradle
examples/helper-script-gradle/gradle/wrapper/gradle-wrapper.jar
examples/helper-script-gradle/gradle/wrapper/gradle-wrapper.properties
examples/helper-script-gradle/gradlew
examples/helper-script-gradle/gradlew.bat
examples/helper-script-gradle/src/.keep
examples/helper-script-gradle/test/ExecTest.groovy
examples/helper-script-gradle/vars/exec.groovy

You can run it by issuing from the examples/helper-script-gradle directory:

./gradlew clean build

or more verbosely:

./gradlew clean build --info

[corporate-gadfly]

I admit it. I'm a noob.

My PR is so simplistic that it doesn't deal with transitive dependencies. When dealing with more complex tests, the original issue of .hpi and lack of transitive dependencies in gradle still remains.

...more progress in next comment...

[corporate-gadfly]

• More progress.
• gradle-jpi-plugin to the rescue.
• PR jenkins-spock when used with gradle #67 has now been updated to include examples/shared-library-gradle directory.
• 2 out of 5 tests fail. Failing tests from DefaultPipelineSpec have the following failure message:

java.lang.IllegalStateException: There is no pipeline step mock for [Deployer.call].
	1. Is the name correct?
	2. Does the pipeline step have a descriptor with that name?
	3. Does that step come from a plugin? If so, is that plugin listed as a dependency in your pom.xml?
	4. If not, you may need to call explicitlyMockPipelineStep('Deployer.call') in your test's setup: block.
	at com.homeaway.devtools.jenkins.testing.JenkinsPipelineSpecification.getPipelineMock(JenkinsPipelineSpecification.groovy:752)

[corporate-gadfly]

@awittha Any interest in pushing this along further?

[corporate-gadfly]

• PR jenkins-spock when used with gradle #67 updated with 100% tests passing.
• basically getSharedLibraryVariables() was looking for .groovy files under vars, so I manually copied them borrowing technique from @kamilszymanski (similar to how the maven setup was doing any way) :

task cleanSharedLibraries(type: Delete) {
    delete "$buildDir/classes/groovy/test/vars"
}

task prepareSharedLibraries(type: Copy) {
    dependsOn tasks.cleanSharedLibraries
    from 'vars'
    include '*'
    into "$buildDir/classes/groovy/test/vars"
}

test {
    dependsOn tasks.prepareSharedLibraries
}

[corporate-gadfly]

PR #67 updated to include whole-pipeline-gradle.