refactor: convert Jenkinsfile to declarative pipeline syntax #14
Conversation
There was a problem hiding this comment.
Looks reasonable. Ideally we'll figure out how to run it before merging.
There are some things about how we handle failure cases that we'll want to change, but I'd be okay with leaving those changes for a separate PR if you want to keep this one strictly about the scripted/declarative syntax.
| // We need to upload the XML reports for visualization in Jenkins. | ||
| // | ||
| // See https://docs.gradle.org/current/userguide/java_testing.html#test_reporting | ||
| junit testResults: '**/build/test-results/unitTest/*.xml', allowEmptyResults: true |
There was a problem hiding this comment.
Thinking about whether we want allowEmptyResults: true here. I guess some modules don't define tests at all; what happens when we run unitTest there? If they don't produce any test-results, then we'd need to allow empty results.
But if they do produce test-results (that just say "0 tests discovered") then we don't have any reason to allow empty results.
There was a problem hiding this comment.
I think they don't produce any test-results if there are no tests 🤔 not entirely sure though
| steps { | ||
| sh './gradlew --console=plain javadoc' | ||
| script { | ||
| if (fileExists("build/docs/javadoc/index.html")) { |
There was a problem hiding this comment.
can this fileExists thing go inside a when expression instead of script?
There was a problem hiding this comment.
afaik it cannot, as we need to execute something before we can check and when IIRC is only executed at the very start of / before a stage
|
There are more related changes over in https://github.com/Nanoware/ModuleJteConfig/blob/develop/Jenkinsfile right now, but also an apparent dependency on upgrading Jenkins and some plugins before Declarative will play along nicely with JTE. |
|
Specifically, it's the "Pipeline: Model API" plugin that needs to be upgraded, as supporting declarative pipeline with Jenkins Templating Engine is in the next major revision. And for whatever reason, it's not something we seem to be able to upgrade standalone. So I concur, it looks like we need to upgrade the whole Jenkins controller. |
|
but I also am quite disappointed with the error reporting and troubleshooting for this error, which led me to think: Do we need JTE for this? I don't think we're making use of its templating abilities here. If I understand correctly, we just want to be able to define the pipeline in a way that a module committer cannot override by adding their own Jenkinsfile. I found a couple possibilities but none quite fit:
and as difficult as it was for me to see how it was the use of JTE that made for our failure case here, I don't really have any reason to believe that a similar failure in any of those other plugins would be any less obtuse. 😐 |
|
we upgraded Jenkins and the builds are closer to working now, or at least giving more relevant error messages. |
| String[] jobNameParts = env.JOB_NAME.tokenize('/') as String[] | ||
| String realPojrectName = jobNameParts.length < 2 ? env.JOB_NAME : jobNameParts[jobNameParts.length - 2] | ||
| boolean originNanoware = jobNameParts[0].equals("Nanoware") | ||
| boolean experimental = jobNameParts.length >= 2 && jobNameParts[2].startsWith("X") |
There was a problem hiding this comment.
If the X here is meant to tie it to https://jenkins.terasology.io/teraorg/job/Nanoware/job/TerasologyModules/job/X/ maybe include a link to it? This could get confusing over time if things change and only part of the picture is readily visible :-)
No description provided.