-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gradle example #22
Comments
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. |
You can find working examples at https://github.com/kamilszymanski/jenkins-pipeline-automation-starter. |
@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. |
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 PluginsThere 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 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 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 NeedLooking 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 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. |
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? |
@awittha I don't know much of 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
You can run it by issuing from the
or more verbosely:
|
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 ...more progress in next comment... |
|
@awittha Any interest in pushing this along further? |
|
PR #67 updated to include whole-pipeline-gradle. |
@awittha : anything I can do on my end to move this further along? |
I haven't had time to look over the updates yet; until I find that time I won't know if there's anything I need from you. |
I tried shared-library-gradle, it seems working with my very simple test. What I noticed the maven is more informative when one test failed than gradle, e.g.: `./gradlew test
TestClassSpec > [TestClass] getDirName non service dir FAILED 3 tests completed, 1 failed FAILURE: Build failed with an exception. mvn test "apple" != path
[INFO] "apple" != path [INFO] |
@deblaci 👍 Thanks for the kind words. You can increase verbosity by running
Does that make the output any better? |
@corporate-gadfly Yes, it is very similar to maven :) Thanks. |
I found another implementation of testing via |
Perhaps @ernestojeda could chime in on his experience using |
This PR/Issue should have more visibility. With 0 Gradle experience I was able to get https://github.com/jenkinsci/JenkinsPipelineUnit up and running in a single day. I have been trying to add jenkins-spock for about 20+ hours across multiple weeks and still can't get it to run. I have had the most success since finding this issue but still not able to get things to work correctly. I get
for
adding
results in
|
@shadycuz Hard to comment without looking at a minimal, but complete, example. If your
or, in some cases:
Hope that helps. If you're able to share a minimal example, then more help could be forthcoming. Also make sure
|
We ported our project from maven to gradle (docker-based) earlier this year: Readme under the |
gradle version upped to 6.6.1 in #67. |
Hmm, trying to follow @corporate-gadfly example, and it works until I try to use jenkins-spock (and not just spock) features - at which point I get the oddest error:
and inside the test
.... while writing this up, I started looking at examples by others and found a Workaround was to add this to the
|
Thanks for the comment @mlasevich . In all of the sample projects, I have a section as follows:
Hope that helps. |
FWIW, I had that copied just like that, but for whatever reason it just did not work - it was still appearing in the dependency tree and breaking the tests. I even added that section to any dependency related to jenkins. It was not until I globally blocked it that it worked. |
@mlasevich Same thing for use. We had to apply a broad brush to that icu dependency: https://github.com/edgexfoundry/edgex-global-pipelines/blob/master/build.gradle#L69-L89 |
I appreciate your comments @ernestojeda and @mlasevich . From my experience, with gradle 6.6.1:
and the
|
gradle version bump to 6.7 in #67 . |
@corporate-gadfly I tested, and sure enough, your version seems to work. Upon comparing our setups I traced it down to version of |
thx for the feedback. With latest commits in #67, I ended up using the latest
YMMV. |
YMMV. |
@mlasevich : JPI plugin bumped to |
@shadycuz : Sorry this slipped through the cracks. With the following diff, your
|
Thanks for getting back to me. I kinda stopped development on my public shared-lib because I wasn't happy with the level of testing I was able to accomplish. I felt like most testing was aimed at the jobs and I was more concerned with the library. Will definitely give it another shot soon. It's probably because I'm not experienced with java, if I was I would probably just publish a couple of plugins instead of a shared_lib lol. |
@shadycuz I am personally not sure that developing plugins instead of a shared pipeline library is (in general) preferable. You then may enter Jenkins plugins hell, or have other/additional challenges like release/deployment/update. As always: it depends. ;-) |
I prefer this myself! |
Instead of doing this:
in every test class I simply created a folder called
Anyways, I think that's an issue that shall be solved in jenkins-spock. |
Why not implement something such as
Which is based on #22 (comment) |
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.
The text was updated successfully, but these errors were encountered: