specifying variables on bitten-slave command line

[Mike Schneider]

I know I can run the bitten slave locally by passing the filename of
the recipe like this:

bitten-slave --keep-files --work-dir "c:\bitten-builds\urbansim"
bitten-recipe-urbansim.xml

but the checkout line in my recipe looks like this:
<svn:checkout url="https://svn.ict.usc.edu/svn_urbansim/"
path="${path}" revision="${revision}"/>

which gives me this error:

[INFO ] Executing build step 'checkout'
[ERROR ] svn: Syntax error in revision argument '$revision'
[ERROR ] Build step 'checkout' failed (Build step checkout failed)
[WARNING ] Build step 'checkout' failed
[WARNING ] Stopping build due to failure

So, how do I specify ${revision} and ${path} from the command line?

Thanks

[Bill5107]

Did you find your answer?

I'm up on this right now and searching...

[Mike Schneider]

Nope, I just skipped around that issue when doing local testing.

[Paresh]

I have used this:

<build xmlns:svn="http://bitten.cmlenz.net/tools/svn"
description="title">
<step id="checkout">
<svn:export url="http://utah/repositories/phoenix" path="${path}"
revision="${revision}"/>
</step>
...
</build>

without any problems. It also works with svn:checkout.

Have you got the correct namespace (xmlns:svn=...) in the build tag?


On Aug 12, 10:15 pm, "Mike Schneider" <mikepschnei...@gmail.com>
wrote:

> Nope, I just skipped around that issue when doing local testing.
>

[Bill5107]

But how does that let you run the slave locally in such a way that you
can provide the revision and path...I think that was Mike's original
question (I know it was mine)

I think the short answer to this thread appears to be that "there is
no way to specify the revision and path at the bitten-slave
commandline. (the server adds it to the build tag attributes)"


This leave me with questions on how to make effective use of the
tools:

My suspicion is that I'm going about things the "wrong way" here.
There are 2 reasons I wanted to run locally:

1.) To test a recipe before putting it on the server. - ok, while
testing a recipe I can add attributes to the build tag as the server
does...I just have to remember to remove them before I put it on the
server. Is there a better way?

2.) To convince myself a commit I am about to perform will not break
the build...here what I really want is to avoid checkout (and file
cleanup etc) so that the recipe uses my local workspace. Not sure how
to do this yet. Perhaps there is an "include" type mechanism or
conditional mechanism for recipies (or should be?).. or maybe I just
need to have a different recipe for that.. or maybe I just shouldn't
be trying to do it this way at all?

I'm still trying to get my head around how we want to use Bitten here,
so any suggestions are appreciated.

Thanks all

->slinks off to RTFM some more<-


On Aug 13, 4:33 am, Paresh <Paresh.Sola...@bellfruitgames.co.uk>
wrote:

[Paresh]

I do the same as you for (1).

For (2), I have bitten running on my local machine with a modified
recipe that doesn't checkout, but builds from my local checkout.

Again I'm not sure if that's the best way, but it works for me.

as an aside, I have found Bitten harder to work with than trac because
the documentation is so sparse.

[Mike Schneider]

I use this same technique of commenting out the svn step in my recipe
and running from my local svn copy. Then I specify the work dir and
build dir like this:

bitten-slave --keep-files --work-dir . --build-dir . recipe.xml

That causes it to run my recipe against the local svn copy without
checking anything out or deleting anything when it's done.

This is mentioned on the FAQ.

Mike

[Iain Haslam]

>> For (2), I have bitten running on my local machine with a modified
>> recipe that doesn't checkout, but builds from my local checkout.

> I use this same technique of commenting out the svn step in my recipe

> and running from my local svn copy. Then I specify the work dir and
> build dir like this:
>

> ...

>
> This is mentioned on the FAQ.

I do the same (which is why I wrote that FAQ). There is an additional
advantage that I store recipes in the svn repository, allowing easier
change tracking. All other developers can use the same recipe to run
all tests before a commit, so there's less excuse for breaking the
build...

Cheers,
Iain.