I dont think it is intentional. But I could not reproduce your problems with 1.213.

The steps I tried to reproduce:
1. Execute "export MYSTERY=WORKSFORME" in shell
2. Start hudson through java -jar hudson.war
3. Create a new job
4. Add a ant builder
5. Put the following ant file into workspace
<?xml version="1.0"?>
<project name="test" default="a" basedir=".">
<target name="a">
<property environment="env" />
<echo message="Mystery=${env.MYSTERY}"/>
</target>
</project>
6. Build and check the console output:
[workspace] $ ant a
Buildfile: build.xml
a:
[echo] Mystery=WORKSFORME
BUILD SUCCESSFUL

Is there something Im missing?

Adding mail conversation

----------------------------------------------------------
From Hawkins, Keith

I must I had a typo when I tried this previously.

The symptoms now are I can set and see in the Ant echo statement an
environment variable MYSTERY.
But the environment variable CLASSPATH does not resolve. Perhaps that
is because it is being launched via java -jar hudson.war ??

Here is the build output I see from Ant:

deploy-QA-distribution:
[echo] ${env.CLASSPATH}
[echo] Can you see me

where "Can you see me" is the value I assign to MYSTERY env variable.

----------------------------------------------------------
From Erik Ramfelt

The classpath is available as the java property "java.class.path". Are
you sure that the CLASSPATH env variable is set when starting java
with "-jar Hudson.war"?

----------------------------------------------------------
From Hawkins, Keith

Yes. Because I echo it out in the run.sh in which I call java -jar
hudson.war.

----------------------------------------------------------
From Erik Ramfelt

Can you see the CLASSPATH env in the system information in Hudson? It
seems that some environment vars are not shown in the system
information but I dont know why.

Does the CLASSPATH in the ant script work properly when run outside Hudson?

----------------------------------------------------------
From Hawkins, Keith

In Hudson system information, java.class.path is just hudson.war
whereas CLASSPATH has the values I set in the run script.
If I run the Ant build outside of Hudson, the echo task of env.CLASSPATH
works as expected.

Very strange.

----------------------------------------------------------
From Erik Ramfelt

Yes, but one last question. Can you echo the env variable in a shell
in the job? ie create a shell that has "echo $CLASSPATH"

So it seems some env variables are available in the ant scripts but
not CLASSPATH, correct?

This issue also occurs on Windows batch file scripts.

In the 'System Information' of the slave the CLASSPATH variable is available under the environment variable, but as soon as you do 'echo %CLASSPATH%' this gives you this message: 'ECHO is on.' because the CLASSPATH variable is not available at all.

Im not sure whats wrong and I dont have much experience in the core parts.

Is this issue similar to the JENKINS-7442 issue?

Can someone post exact steps for a testcase that shows the problem in the latest Jenkins release? I did recently make more Jenkins-defined vars get expanded in ant build steps, but I don't think that is related here as you're talking about vars defined in the external environment.

With Jenkins 1.408, we do see most of the environment variables inherited from the slave and/or configured being available in the Ant build step with the exception of the CLASSPATH variable. Presumably, a special case?

same problem here, using jenkins 1.428. to test, this way it works(using execute shell):
DISPLAY=:99 ant

using execute shell to export DISPLAY variable and then invoking ant, don't.

I had the same problem: running Jenkins (ver 1.474) on windows.
FLEX_HOME is set in the environment but is not found when ant is called.
I saw failures such as "cmd.exe /c "ant.bat blah blah blah" in my failed build log.
I added "set FLEX_HOME=C:\flex_sdk_4.0.0.14159A" to my ant.bat.
This didn't work.

Then...I looked at the configuration for the Project/build.
and there it was:
I checked [x] "this build is parameterize"
I added "String Parameter" which let me set the name/value I wanted.

The build worked after that. No value pulled from the environment but I can set any String Parameter I want now.

It's tedious but it works.

Diego,

It makes sense that "ant" and "DISPLAY" must be executed on the same "execute shell" line. Each shell line gets executed inside a separate shell. Placing the call on a single line causes it to execute inside the same shell.

Hi,

Talking about a little bit different problem I'm experiencing, but still related to this thread (and the one marked as duplicated):
It's not being possible to use varibles defined by Jenkins inside ant scripts.

This used to work before updating Jenkins' version. I'm just calling an ant script on post build and using ${BUILD_VERSION} inside of it, what is not working.

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.

Is it reproduced with a recent version?

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, thanks Jesse

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.

Based on comments, this issue was fixed.