0

When using a piece of test code running 'sh' vs 'execute' i noticed a great differences in environment variables. It quickly looked as if two totally different host were involved - even if lines of invocation are only some two lines away on the very same script level.

My test codes are about that (simplified/principle):

sh("set")
[ "sh", "-c", "set" ].execute()

A sample build resulted in these outputs:

sh:      HOSTNAME='jenkins-master-build-node-820bj'

execute: HOSTNAME=jenkins-master-8-v95jg

Many other differences in environment variables were observed. Rationale: This is definitely not the same runtime environment and probably not even the same computer system. I am puzzled at the moment!

How could that be understood? How could that be controlled? Indeed I want the execute() call behave identical to sh().

Alexander Stohr
  • 159
  • 1
  • 18
  • this one might be related - or maybe not. it gives some insights to some habits in that area. https://stackoverflow.com/questions/19634733/difference-between-execute-groovy-script-and-the-execute-system-groovy-script-in – Alexander Stohr Jan 26 '21 at 14:51
  • maybe this hints for the same facts: Groovy scripts will run in standard JVM by default, but with some extra efforts execution on the build slaves is possible. - relevance undecided. https://stackoverflow.com/questions/37144549/executing-groovy-scripts-on-jenkins-slaves – Alexander Stohr Jan 26 '21 at 14:57
  • this one is a hot match when it comes to the fine print comments at the end - but it does not at all answer it. https://stackoverflow.com/questions/62282605/error-while-executing-another-process-through-groovy-script – Alexander Stohr Jan 26 '21 at 15:42

0 Answers0