Variable from shell script to Jenkins job

[Naumenko, Roman]

Jenkins experts,

Does anybody remember how to pass variable from shell execution inside the job to Jenkins itself?

Say there is pre-step:
varID=(grep something ${WORKSPACE}/pom.xml | cut something else)

Is it possible to use $varID in further non-shell steps in the job?

--Roman

_______________________________________________________________________

This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.

[Ginga, Dick]

I think you can write things to a file from your shell, then make the next build step Inject environment variables plugin and those values are now available to build steps and other shell steps.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mandeville, Rob]

We’ve got a technique for this at our shop.  It requires the envInject plugin.

 

You write a line such as:

 

echo “varID = $varID” > export_props.properties

 

In the step after the shell step, create an “Inject environment variables” step that reads from export_props.properties.

 

Now, the contents of export_props.properties is injected into the job itself, and will be injected into shell steps as environment variables.

 

--Rob

 

From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com] On Behalf Of Naumenko, Roman
Sent: Thursday, January 23, 2014 10:50 AM
To: jenkins...@googlegroups.com
Subject: Variable from shell script to Jenkins job

 

Jenkins experts,

--

You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.

[Maureen Barger]

We do this as well FWIW.

[Naumenko, Roman]

Yup, just checked and it works just fine. Gonna be doing a lot of this from now on :)

Thank you,
--Roman

[Adrian Paraschiv]

Hello Rob,

I have a couple of questions:
1. The line "echo “varID = $varID” > export_props.properties" is run on the jenkins server or on the remote ?
2. If I need something like this on the remote server for a script that jenkins runs:
..........
export APPS="/opt/play/apps"
export ACE="$APPS/default-ace/ACE"
..........

What would be the best method to use:
1. Add build step (before Execute shell ) "Inject enviromnet variables"  and at the "Properties Content" I add the above...or
2. At "Build Environment" check "Inject environment variables to the build process" and add the above at "Properties Content"

Thanks

[Rob Mandeville]

In the technique below, the echo lines are run on the remote (slave node).  The “Inject environment variables” step works on the slave node and reads any files it needs from there, not the server.  Also, this technique was built to allow one shell step to calculate the values of environment variables and inject them into later steps.  Given your specific case, you don’t have to get this involved.

 

The environment variables in your case below don’t appear to depend on anything the job does.  These variables look like properties of the machine you’re running on.  While the envInject technique would still work, you could set the environment variables either at the build environment section of the job or in the node configuration.  In either case, you’ll have to specify ACE as “/opt/play/apps/default-ace/ACE”; “$APPS/default-ace/ACE” only makes sense within a shell.

 

There’s a good argument to be had for inserting these variables in the slave node itself, as they describe information specific to that host rather than specific to any job.  If you do set the environment variable at the slave level, make sure to reboot the slave by selecting Disconnect on it (slaves should restart themselves)—until the slave process reboots, it will have the old values for environment variables.

 

--Rob (Same Rob, different job)

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/71034386-ff4a-49d7-b03e-f5946f3269f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Click here to report this email as spam.

---

This e-mail and the information, including any attachments it contains, are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.