ci: build with java 11? [spike] #104
Conversation
| axes { | ||
| axis { | ||
| name 'JAVA_VERSION' | ||
| values 'java8', 'neo-java' | ||
| } | ||
| } | ||
| agent { | ||
| label env.JAVA_VERSION |
There was a problem hiding this comment.
I ended up using the labels as the axis values, but that doesn't feel great.
How would I do a map from values to labels in a declarative pipeline?
Or maybe this is the way to go, and it's just a matter of naming labels consistently?
| javaDoc(), | ||
| taskScanner(includePattern: '**/*.java,**/*.groovy,**/*.gradle,**/*.kts', lowTags: 'WIBNIF', normalTags: 'TODO, FIXME', highTags: 'ASAP') | ||
| javaDoc(id:"javaDoc-$JAVA_VERSION", name: "JavaDoc $JAVA_VERSION"), | ||
| taskScanner(id:"tasks-$JAVA_VERSION", name: "Tasks $JAVA_VERSION", includePattern: '**/*.java,**/*.groovy,**/*.gradle,**/*.kts', lowTags: 'WIBNIF', normalTags: 'TODO, FIXME', highTags: 'ASAP') |
There was a problem hiding this comment.
taskScanner works purely on the source text so it's not really useful to include in the matrix. Doing it once would be sufficient.
| @@ -33,6 +46,7 @@ pipeline { | |||
| } | |||
| stage('Publish') { | |||
| when { | |||
| expression { env.JAVA_VERSION == 'java8' } | |||
There was a problem hiding this comment.
I put this in the matrix so it can keep going on the java8 node it used to build.
(Not publishing a java11 build because that sounds like a different kettle of worms.)
But maybe this should be outside the matrix so it doesn't happen unless the java11 tests succeed?
|
This is interesting, nice work 👍 I haven't tried using matrix in pipeline land at all, be it declarative or scripted. Additionally I've started using multiple labels as requirements, and I'm not sure how those two approaches would get along. Not that we can't just go to single (perhaps more detailed) labels. I need more time to dig into this some to really be able to contribute much of anything sensible I think, and there are a few things in front of it :-) |
Using |
|
This deserves more time from me but I dunno when that'll be. I only remember matrix from way long ago, where it had some warts. Without really having the knowledge to judge its state today - I do wonder if it would be the best approach, especially if there are some stages where it doesn't make sense to spread across the full matrix. The main alternative I can think of is just clever use of stages and parallel but with hard coded targets (dunno if scripted would have more flexibility there or not needed). Not sure if we're likely to go much past feeding 2 JDKs to the matrix? |
Experimenting to see how we could keep building with whatever lowest-common-denominator JDK we need, but also run the test suite under a newer JDK.