brosmar
commented
1 year ago Happy New Year to the template engine Team.
Is there something missing in my description? The Bug is still a problem for me. Is there a reason why it is not assigned.
Closed brosmar closed 1 year ago
brosmar
commented
1 year ago Happy New Year to the template engine Team.
Is there something missing in my description? The Bug is still a problem for me. Is there a reason why it is not assigned.
brosmar
commented
1 year ago We Installed the new Plugin Version 2.5.3 and restarted the jenkins server. The job is still crashing. The callstack dump is 100% the same as stated above. No Line has changed.
brosmar
commented
1 year ago Sorry, the comment before is false. The job is still crashing at the same place but the callstack is different. Please see the attached dump file 2.5.3versionDump.txt .
`[Pipeline] End of Pipeline hudson.remoting.ProxyException: java.lang.UnsupportedOperationException: Refusing to marshal org.jenkinsci.plugins.docker.workflow.Docker$Image for security reasons; see https://www.jenkins.io/redirect/class-filter/
---- Debugging information ---- message : Failed calling method cause-exception : java.lang.UnsupportedOperationException cause-message : Refusing to marshal org.jenkinsci.plugins.docker.workflow.Docker$Image for security reasons; see https://www.jenkins.io/redirect/class-filter/ method : org.boozallen.plugins.jte.init.governance.config.dsl.PipelineConfigurationDsl$ConfigBlockMap.writeObject() -------------------------------`
jglick
commented
1 year ago Sounds like there are deeper structural problems with either this plugin or your attempted usage of it (or both).
brosmar
commented
1 year ago Do you have an Idea what could be the structural root cause? The Job is breaking in an Lifecycle Hooks lifecyclehook.txt. The last wiritten trace is "trace1" in line 63.
jglick
commented
1 year ago Sorry, no idea, I am not a maintainer and have little knowledge of this plugin.
brosmar
commented
1 year ago I reduced the error to a docker.image call and replaced it with shell commands. And now the pipeline works fine.
When running the following code:
def cmd = "mvn -B -s settings.xml ${env.MAVEN_OPTIONS} sonar:sonar ${args.collect { "-D" + it }.join(' ')}".toString()
//def cmd = "mvn -B -s settings.xml clean"
println "running command: $cmd \ninside container: $globals.localBuildImage".toString();
if (true) { // when set to true the pipeline crashes if false all is ok
docker.image(globals.localBuildImage).inside {
sh cmd
}
} else {
def containerId = sh (script: "docker run -d -it $globals.localBuildImage $cmd", returnStdout: true).trim()
sh "docker wait $containerId"
sh "docker container logs $containerId"
}The pipline creates the Dump: 2.5.3versionDump.txt
When i change the line
if (true) { // when set to true the pipeline crashes if false all is ok
to
if (false) { // when set to true the pipeline crashes if false all is ok
The pipeline works fine and dose not throw an exception.
Do you have an explanation for this workaround? Is there a problem with the templating engine or with the "docker-workflow" plugin. ( The old templating engine 1.x was working fine with the docker-wokflow plugin )
jglick
commented
1 year ago Is there a problem with the templating engine or with the "docker-workflow" plugin
Clearly the templating-engine plugin is at fault here, specifically something added to https://github.com/jenkinsci/templating-engine-plugin/blob/f73cae43a50c20387b697d8d376edd8dbf960fed/src/main/groovy/org/boozallen/plugins/jte/init/primitives/TemplatePrimitiveCollector.groovy#L51 whose purpose I can only speculate about.
That said, as an original author of docker-workflow, I do not recommend using the withDockerContainer step (for which docker.image(…).inside {…} is syntax sugar), or at least abandoning it at the first sign of trouble.
Anyway, based on the error here, another workaround might be to run the withDockerContainer step directly, without the docker DSL sugar.
brosmar
commented
1 year ago Do I understand correctly:
docker.image().inside() should not be used in the Jenkins Templating Engine script
The reason for that is the mentioned Line: "List<TemplatePrimitiveNamespace> namespaces = [] "
But nobody is taking care of this since weeks.
Is the Jenkins Templating Engine dead?
steven-terrana
commented
1 year ago no, it's not.
@jglick contributed https://github.com/jenkinsci/templating-engine-plugin/pull/312 which was released in version 2.5.3
can you please try upgrading to see if this resolves your issue?
jglick
commented
1 year ago steven-terrana
commented
1 year ago thanks @jglick,
@brosmar - i'd like to help but i'm unsure how to without being able to reproduce the bug.
Jenkins Version
CloudBees CI Client Controller 2.375.1.1-rolling
JTE Version
2.5.2
Bug Description
I am migrating form Jenkins Templating Engine 1.x to 2.5.2. I have made the necessary code changes. All global variables where now accessed using the "globals" object. In our Test Jenkins I am testing the migrated sources.
During a Complex pipeline the Job terminates with the exception:
hudson.remoting.ProxyException: java.lang.UnsupportedOperationException: Refusing to marshal org.codehaus.groovy.runtime.GStringImpl for security reasons; see https://www.jenkins.io/redirect/class-filter/The complete log starting with the problematic Parts where the exception is thrown you can find in the Relevant log output below.
The library source that is executed in the moment of the exception is a during a @BeforeStep. But a similar error was thrown during a normal Step. A similar Issue was already raised: https://github.com/jenkinsci/templating-engine-plugin/issues/207. I tried the mentioned "Text".toString() workaround with no success.
The exception occurs in the following beforeStep() function. "trace 1" is written in the output "trace 2" not. This is the function in progress:
Code starts here: -------------------------------------- `@BeforeStep void beforeStep() { println """ +++ called library: $hookContext.library, function: $hookContext.step +++ """ if (hookContext.step.equals("check_pr") || hookContext.library.equals("git_scm")) { //vars not set println """do nothing because: hookContext.step.equals("check_pr") || hookContext.library.equals("git_scm")
+++ return library: $hookContext.library, function: $hookContext.step +++ """ return } println "trace 1" env.stepFailed = "false".toString() println "trace 2" //TODO: move to initialize env.githubInit = (env.githubInit) ? true : false
println """ +++ return library: $hookContext.library, function: $hookContext.step +++ """ }` Code ends here: -------------------------------------- (The conde annotation dose not work correctly)
Do you have an clue(glue) to fix this.
Thanks for your support Martin
Relevant log output
Steps to Reproduce
I only have my complex test system. I have no small code fragment to reproduce it.