I was thinking of having an ant task that computes build.id from svn
unless build.id is already set. Then presumably for a source distro,
we would set build.id in lps.properties, just like we set version and
release. Wouldn't that work?
On 2006-06-24, at 17:27 EDT, Benjamin Shine wrote:
> The ant tasks below are actually not in the build process anymore.
> In the current scheme, build metadata is determined in build-tools/
> nightly/nightly-go.sh, then passed in as a parameter to ant like so:
>
> ant -Dbuild.revision=${buildnum} -Dbuild.branch=${branch} -
> Dbuild.version=${lpsversion} etc..
> which figures out..
> <property name="path.tag" value="http://svn.openlaszlo.org/$
> {build.project}/builds/${build.name}" / >
>
> That invocation of ant calls the svn-make-tag target, which copies
> http://svn.openlaszlo.org/${build.project}/${build.branch}
> to ${path.tag}
>
> ...which is then checked out to ~/builds/${build.name}
>
> and then the *normal* $LPS_HOME/build.xml is finally invoked:
> <target name="do-linux-build" if="linux.do" depends="init">
> <ant dir="${tmp.dir}/${build.name}" target="${build.target}"
> inheritAll="false">
> <property name="LPS_HOME" value="${tmp.dir}/${build.name}" />
> <property name="ANT_HOME" value="${env.ANT_HOME}" />
> </ant>
> </target>
>
> Which is the long way of saying: No, the build.id that I create for
> nightly builds is not available at compile-time for the server.
>
> How about an ant task that goes into $LPS_HOME/build.xml that sets
> up a property named build.internalid... and then you access it with
> System.getProperty()? Our source distro needs to be able to build
> when there's no svn around. I *hate* it when source accesses
> environment variables; a few places where this happened made it a
> headache to run the builds as cron tasks, which have a very minimal
> environment.
>
> Is there a java api for svn? Errg. Just what we need.
>
> On Jun 24, 2006, at 1:40 PM, P T Withington wrote:
>
>> So you are actually setting build.id? Given svn's ability to
>> output to an xml file, I'm tempted to just use that directly in
>> server/LPS.java to create the build information for the canvas.
>>
>> On 2006-06-24, at 15:28 EDT, Benjamin Shine wrote:
>>
>>>
>>> On Jun 24, 2006, at 11:03 AM, P T Withington wrote:
>>>
>>>> That sounds like exactly what I want. How can I get that value
>>>> into build.id from ant? Is there an ant task that will run
>>>> shell commands?
>>>
>>> I was doing this in the nightly build's build.xml for a while,
>>> but I switched to doing it in bash because I needed to be able to
>>> dictate the rev number from a script, not just use whatever the
>>> HEAD is. But something like this will do what you want. You will
>>> need subversion 1.3.1 -- that is the first client which supports
>>> svn info --xml. Also, it would be a good idea to remove the
>>> repository.xml file after you get what you need from it.
>>>
>>> <target name="get-rev-number" unless="done.get-rev-number">
>>> <sequential>
>>> <!-- Get the current repository information -->
>>> <exec executable="svn" output="repository-info.xml">
>>> <arg value="info" />
>>> <arg value="--xml" />
>>> <arg value="http://svn.openlaszlo.org/$
>>> {build.project}/${build.branch}" />
>>> </exec>
>>> <property name="done.get-rev-number" value="true" />
>>> </sequential>
>>> </target>
>>>
>>> <target name="setup-names" depends="get-rev-number"
>>> unless="done.setup-names">
>>> <!-- Load repository information into properties -->
>>> <xmlproperty file="repository-info.xml"/>
>>> <property name="revision" value="${info.entry(revision)}" />
>>> <property name="build.name"
>>> value="build-${info.entry(path)}-${revision}" />
>>> <property name="path.tag"
>>> value="http://svn.openlaszlo.org/${build.project}/
>>> builds/${build.name}" />
>>>
>>> <!-- print a lot of diagnostic information -->
>>> <echo message="revision is ${revision}" />
>>> <echo message="build.name is ${build.name}" />
>>> <echo message="path.tag is ${path.tag}" />
>>>
>>> <property name="done.setup-names" value="true" />
>>> </target>
>>>
>>>
>>>>
>>>> I like your metadata idea. I suppose what you really want to
>>>> know is if there are un-checked-in changes in the tree, but that
>>>> would be too slow in svn.
>>>
>>> I think checking for local changes doesn't require network
>>> access. It *shouldn't* at least. Aha:
>>> "With no args, print only locally modified items (no network
>>> access)."
>>> So the slowness comes from our gigantor tree. It could be fast if
>>> you list the top-level directories you actually care about...
>>>
>>> svn status lps WEB-INF| sed -e /.lzl$/d -e/.class$/d >
>>> localchanges.txt
>>>
>>> then do something creative with localchanges.txt to make it
>>> visible in the canvas...
>>> I'm liking this. Go Tucker!
>>>
>>>
>>> benjamin shine
>>> software engineer
>>> [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>
> benjamin shine
> software engineer
> [EMAIL PROTECTED]
>
>
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
