-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
Platform: All, OS: All
It appears that environment variables available in the Hudson configuration
(i.e. visible in the Hudson System Information page) are NOT passed to Ant
builds when Hudson launches a configured Ant installation.
This does not seem intentional. Is this by design?
For example, I declare an environment variable MYSTERY='This is a puzzler' and
make it available in the shell by which I launch Hudson (java -jar Hudson.war)
I add an <echo> statement in my Ant build script to print out the value of this
env variable. When running Ant outside of Hudson, the value of MYSTERY is
displayed properly. When running Ant inside of Hudson, the value is not
resolved even though Hudson displays the value of MYSTERY properly in the
Environment Variables section of the System Information page.
This seems unexpected.
Is this a known issue?
- is duplicated by
-
-
- Resolved
-
[JENKINS-1640] Environment variables not passed through to Ant tasks
This is happening to me too. I have some projects where the environment variables pass through just fine and others in which the same variables do not. Here's the output of one that's not working:
[echo] Workspace Directory: ${env.WORKSPACE}
[echo] Build Number: ${env.BUILD_NUMBER}
Differences between the 2 projects?
- Broken project builds periodically
- Broken project discards old builds
- Working project is parameterized
Quite perplexed =)
UPDATE
I feel stupid. That's what happens when you forget
<property environment="env" />
My bad! Sorry I cluttered up the comment feed.
karlie verkest
added a comment - - edited This is happening to me too. I have some projects where the environment variables pass through just fine and others in which the same variables do not. Here's the output of one that's not working:
[echo] Workspace Directory: ${env.WORKSPACE}
[echo] Build Number : ${env.BUILD_NUMBER}
Differences between the 2 projects?
Broken project builds periodically
Broken project discards old builds
Working project is parameterized
Quite perplexed =)
UPDATE
I feel stupid. That's what happens when you forget
<property environment= "env" />
My bad! Sorry I cluttered up the comment feed. FYI: Just tested using Jenkins v1.574 and ant plugin v1.2, and ${env.WORKSPACE} worked perfectly when used together with
<property environment="env" />
in my build.xml.
stefanthurnherr
Wow! It has been years since I have not heard news about an issue with a number such as JENKINS-1640.
So we may be able to close an issue opened for more than 6 years.
That's good news.
jglick
I have assigned to you, because you are a good source of confirmation for closing.
Feel free to reassign to D. or whatever.
@stefanthurnherr I think this issue was about something unrelated: whether environment variables defined on the Jenkins process (i.e., not something like $WORKSPACE) are picked up by forked build steps it runs.
I have no particular information about this. If it remains reproducible in current versions of Jenkins, someone interested should track down why and offer a fix.
Ok I tried both ${env.PATH} and ${env.USER}, where both PATH and USER are listed under "Environment variables" at <jenkins-instance>/systemInfo. Used in an <echo> task they resolve correctly and print out the same (for USER) or similar value (for PATH: jdk location gets prefixed) as shown under <jenkins-instance>/systemInfo.
Same problem here. I have an ant task that uses ${env.HOSTNAME} to pick up a .properties file depending on the hostname of the machine.
It turns out that that specific variable doesn't expand, although many others do just fine.
I checked System Information, and HOSTNAME is correctly set under Environment Variables. Echoing the properties filename I get this, though:
[echo] /mnt/slave/workspace/Platform_develop_Build-Common/git/Common/${env.HOSTNAME}.build.properties