determine which environment your running in

[Chris Blackwell]

I have a build script which i run locally and on our testing server.
currently i have two targets runOnLocal and runOnTesting. These are
wrappers to the main target, which is called passing in a hostname
param for the mxunittask.

Is there a way to determine which environment the build script is
being run from and set these params automatically?

Chris

[Marc Esher]

One "old trick" is to use the "available" task and then set a property
based on the result. So probably your test environment has access to
"10.0.X.Y" (or whatever), but local doesn't. So you'd have something
like:

<condition property="hostname" value="whatever" else="somethingelse"
<available file="\10.0.X.Y\C$" type="dir" property="inTest"/>
</condition>

My preferred solution for this is to have host-specific properties
files that get sucked in prior to the main build.properties file:

<echo message="Attempting to include
properties/${user.name}.properties for any property overrides. Then
including properties/build.properties for default props"/>
<property file="properties/${user.name}.properties" />
<property file="properties/build.properties" />

And so on the test server, probably the build runs under a specific
account, like "app_admin" or whatever. so I'd have an
app_admin.properties file, with stuff like:

test.host=TestServerHost
test.port=TestServerPort

etc.

I also like this approach because it's team-friendly... each person on
the team (assuming they have different user.name values) can have
their own properties file, and so the build becomes much less
dependent on a specific server setup with respect to host names, path
locations, etc.

Marc

>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups "mxunit" group.
> To post to this group, send email to mxu...@googlegroups.com.
> To unsubscribe from this group, send email to mxunit+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mxunit?hl=en.
>

[Jim Priest]

You can access system environment variables from Ant - you could pull something from that?

See the environment property of the property task:

http://ant.apache.org/manual/Tasks/property.html 

I did a blog post this awhile ago but it appears my syntax highlighter is screwing up the code (will try to fix that) :)

http://thecrumb.com/2009/04/24/using-environment-properties-in-ant/ 

I like Marc's solution to reference a user account as well. I usually encourage this anyway because then people can commit their own property files to version control... 

       property file="${user.name}.properties" 

       property file="build.properties" 

Jim

[Chris Blackwell]

Thanks marc,

I thought that environment variables where going to be the way to go,
but after a fair bit of reading and messing around with
<echoproperties /> i've found it to be a less than ideal approach.
Relying on something set at the os level didn't seem like a reliable
way to do it.

So, what i've settled on is using properties files for each
environment as you've suggested but manually passing in a parameter to
the ant script.

In eclipse, i'm adding a BUILD_HOST property via the run
configurations property tab.
And in jenkins i'm passing it in via a java option to the invoke ant
build step, -DBUILD_HOST=whatever

Cheers, Chris

[Marc Esher]

On Wed, Dec 21, 2011 at 7:11 AM, Chris Blackwell <ch...@team193.com> wrote:
> Thanks marc,
>
> I thought that environment variables where going to be the way to go,
> but after a fair bit of reading and messing around with
> <echoproperties /> i've found it to be a less than ideal approach.
> Relying on something set at the os level didn't seem like a reliable
> way to do it.
>
> So, what i've settled on is using properties files for each
> environment as you've suggested but manually passing in a parameter to
> the ant script.
>
> In eclipse, i'm adding a BUILD_HOST property via the run
> configurations property tab.
> And in jenkins i'm passing it in via a java option to the invoke ant
> build step,  -DBUILD_HOST=whatever

Another fine approach.