-
Improvement
-
Resolution: Unresolved
-
Major
-
None
Currently EnvStep only accepts String array.
But it would be nice if it could accept Map<String, String> too
and convert it to a String array.
Right now I have to do this in a shared library.
def call(Closure body) {
deleteDir()
def scmVars = checkout scm
def list = []
scmVars.each { k, v -> list << "${k}=${v}" }
withEnv(list) {
body()
}
}
- is duplicated by
-
JENKINS-54930 withEnv should accept Map as well as List
-
- Closed
-
- relates to
-
-
- Open
-
- links to
[JENKINS-46124] EnvStep convert map to list
Another solution which would help us is to add an option to the checkout command to inject the environment variables directly instead of only returning them.
I know you work a lot on this stuff.
Is this something you find useful?
Thank you in advance!
With best regards,
Tom.
Hey tom_ghyselinck when using declarative pipeline you don't have to use checkout scm because the job is configured to use scm and the declarative pipeline will just checkout from that
Hi casz,
It depends 
I use skipDefaultCheckout true in my pipeline options.
I updated my comment accordingly.
Thank you for the suggestion anyway!
With best regards,
Tom.
Databinding in Jenkins, including for Step, does not generally handle Map. Unfortunately it does not generally handle List<String> either, necessitating a StepDescriptor.newInstance override (JENKINS-27901). So I suppose this step could accept Map<String, String> as a convenience.
Anyway for purposes of the stated request, I would consider it a defect in pipeline-model-definition-plugin that it even allows you pass such a function call as an argument. That is a Scripted thing which should not exist in Declarative, just as the def keyword is forbidden. What you actually want is a declarative option to perform a standard checkout in a given stage. So file that separately please, unless it suffices to move skipDefaultCheckout to the other stages rather than being a top-level option, in which case you do not need anything at all.
Did anyone ever file a separate issue to create an overload of withEnv which takes a Map<String, String>? Indeed, the overload to pass a Map would be convenient for us as well. I assumed the reason for the current signature was that Groovy's underlying string helper function "execute()" takes a String[] called envp for environment variables, so withEnv was designed in such a way that the env vars could just be passed through without a type conversion. Otherwise, I can't imagine why it was designed this way.
Of note, it seems the GDSL file currently says it takes a Map, which appears to be simply incorrect.
method(name: 'withEnv', type: 'Object', params: [overrides:Map, body:'Closure'], doc: 'Set environment variables')
This is not as easy as it would seem.
Adding a second @DataBoundConstructor since the method is final seems unsupported and throws error
Changing the code to have two @DataBoundSetter changes the step to ignore takesImplicitBlockArgument suddenly it wants named arguments.
javax.annotation.processing.FilerException: Attempt to reopen a file for path C:\git\code\workflow.basic.steps.plugin\target\classes\org\jenkinsci\plugins\workflow\steps\EnvStep.stapler
[ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacFiler.checkFileReopening(JavacFiler.java:742)
[ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacFiler.createResource(JavacFiler.java:534)
[ERROR] at org.kohsuke.stapler.jsr269.AbstractProcessorImpl.createResource(AbstractProcessorImpl.java:81)
[ERROR] at org.kohsuke.stapler.jsr269.AbstractProcessorImpl.writePropertyFile(AbstractProcessorImpl.java:67)
[ERROR] at org.kohsuke.stapler.jsr269.ConstructorProcessor.write(ConstructorProcessor.java:98)
[ERROR] at org.kohsuke.stapler.jsr269.ConstructorProcessor.access$000(ConstructorProcessor.java:28)
[ERROR] at org.kohsuke.stapler.jsr269.ConstructorProcessor$1.visitExecutable(ConstructorProcessor.java:36)
[ERROR] at org.kohsuke.stapler.jsr269.ConstructorProcessor$1.visitExecutable(ConstructorProcessor.java:32)
[ERROR] at jdk.compiler/com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1964)
[ERROR] at java.compiler@11.0.6/javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:153)
[ERROR] at java.compiler@11.0.6/javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:140)
[ERROR] at java.compiler@11.0.6/javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:189)
[ERROR] at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:1447)
[ERROR] at java.compiler@11.0.6/javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:153)
[ERROR] at org.kohsuke.stapler.jsr269.ConstructorProcessor.process(ConstructorProcessor.java:57)
[ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:980)
[ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:896)
[ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1222)
[ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1334)
[ERROR] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1258)
[ERROR] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:936)
[ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
[ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:147)
[ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
[ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
[ERROR] at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126)
[ERROR] at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
[ERROR] at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1134)
[ERROR] at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:187)
[ERROR] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
[ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
I would suggest leaving the databinding alone and implementing CustomDescribableModel.
Searching on GitHub does not give many results, perhaps you could point to a good implementation:
https://github.com/search?q=org%3Ajenkinsci+CustomDescribableModel&type=Code
Reading on the CustomDescribableModel I would have to implement a customInstantiate
Created https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/105 thanks to jglick's suggestion 
Hi,
This would be a great improvement for use with declarative pipeline.
We now have the case where we only perform a checkout in the stages where applicable.
It could help to have some syntax like:
pipeline { options { skipDefaultCheckout true } stages { stage('Build') { steps { withEnv(checkout(scm)) { echo 'printenv' echo 'Perform the build' } } } } }On the other hand, we still have the case that checkout and withEnv are in separate steps.
We would something like the following (not that this example won't work because of the variable assignment!):
pipeline { options { skipDefaultCheckout true } stages { stage('Build') { steps { def scmVars = checkout(scm) echo 'Preparing the build' withEnv(scmVars) { echo 'printenv' echo 'Perform the build' } } } } }Our current workaround is to set the scmVars as a global variable and then "translate" it into a list for use with withEnv:
import groovy.transform.Field @Field XRA31_SCM_VARS = null /** * Sets the XRA31_SCM_VARS variables to the output of the `checkout` command */ def xra31_prepare_source(steps, scm) { XRA31_SCM_VARS = steps.checkout changelog: false, poll: false, scm: scm } def flatten_map(Map m) { List l = [] m.each { k,v -> l.add([k, v].join('=')) } return l } pipeline { options { skipDefaultCheckout true } stages { stage('Build') { steps { xra31_prepare_source(this, scm) echo 'Preparing the build' withEnv(flatten_map(XRA31_SCM_VARS)) { echo 'printenv' echo 'Perform the build' } } } } }It would be great to see a solution for the latter case since we use/need it extensively.
With best regards,
Tom.