[PLUG] headless builds and automatically generated files

[Ted Kubaska]

Thanks...most of my problem was not understanding what it was I wanted
to do. That's why I kept talking about conventions.

What we really want to do was check out the HEAD and then build and
timestamp the build without tagging the new build in the CVS repository.
Because it's just a daily build, meant to be the latest snapshot for our
users. We do tag our releases and interim releases and these are
supported. The daily build is not.

Renaming files does not work because the jar names *must* correspond to 
the Bundle-Version in the jars.

It turns out that the solution is to set the property
forceContextQualifier to the timestamp. And you can do this in the
build.properties file, which is a standard file in this headless eclipse
build environment. Or even in the ant file called by cruisecontrol as
follows (D means we're in a daily build).

<condition property="forceContextQualifier" value="${timestamp}">
  <equals arg1="${buildType}" arg2="D" />
</condition>

I hadn't known about this property ... but it's right there in the docs.
And the docs are written well enough ... there's just so much of them.

Comments below also.


On Sun, 2007-06-10 at 08:05 -0500, David Fleck wrote:
> On Fri, 8 Jun 2007, tkubaska at charter.net wrote:
> > [...]
> > The automatic system uses the same parameter to construct the name of 
> > the jar file it makes that it does when it checks out the files. If you 
> > set this parameter to what you want the jar files to be named, the CVS 
> > checkout fails because there are no files in CVS tagged with that name.
> 
> Let me rephrase what you said to make sure I understand it:
> Your eclipse plugin takes a tagname as a parameter, checks out code with 
> that tag, builds it, jars it, and sticks the name of the tag into the jar 
> name?
Yes. The way the headless build environment operated was that you
checked out HEAD or a tag, built, and then either HEAD or that tagname
was incorporated into the build naming conventions. I couldn't see how
to break the connection between the tag of what we checked out and what
we built with. Well, you can see where to break that link but it's in
automatically generated files that get re-generated every time.

But there was a property that let me do this, described above.

> 
> > What I want to do (I think I want to do this, but if it's too strange 
> > then I want to do what other people do) is check out the HEAD (because 
> > the HEAD should always be buildable and if it isn't I want to know), and 
> > build the HEAD. If the HEAD builds I want to zip up the resulting jar 
> > files and stick them on a site for download by our users. I don't want 
> > these jar files with HEAD in their names. Rather I want their names to 
> > have a unique name (like a timestamp, preferable the timestamp when I 
> > started the build, which mostly takes under 10 minutes).
> > 
> > For a while I thought I wanted to get the latest tagged version, but I 
> > don't think so anymore. The tagged versions are our releases and interim 
> > realeases, not our daily builds. So they always build (I discreetly 
> > coughed here). I don't think I want to save and tag our daily builds 
> > even when they work.
> > 
> > Here is a question ... do people save and tag daily builds that are just 
> > daily builds? You'd end up with a lot of tagged versions in CVS. A build 
> > only occurs if the CVS changes, but in this environment that is just 
> > about every day.
> 
> In our shop, we use the cvs -D 'date' parameter to check out code as it 
> was at a particular time (usually a few minutes before the build starts).  
> We generate the 'date' argument programmatically, and use a variant of it 
> to identify the build packages (which are not jar files).  We log the 
> 'date' argument used, so that we can get back to that specific set of code 
> later.  (We actually did tag every build for a while, but that became 
> ridiculous.)
This is good input ... thanks. An interesting and useful approach. Yes,
we were thinking abut tagging every release but projected that this
would soon turn out to be unwieldy. I want daily builds to be just
that ... a daily build to see if it works, but unsupported for continual
use. But there are users who want them. Supported builds are tagged. 
> 
> Can you get ant or eclipse to feed a date parameter to cvs?
> 
> > What I've (through a lot of frustration) discovered is that there does 
> > not appear to be a way of breaking the connection between the name used 
> > for checkout and the name used for jarring. If there is, I would be 
> > thrilled to find it.
> >
> > The solution may turn out to be as simple as letting this automated 
> > system build the way it wants to and then rename the files at the end. 
> > This would probably mean deleting the generated zip file and then 
> > rezipping with the renamed jar files.
> 
> Afraid I don't know enough about ant or eclipse to help here. Your problem 
> sounds more and more like a limitation of the ant script (or of ant 
> itself).  Your delete-and-rezip idea may be the most direct answer, even 
> if it's not as clean as you'd like.
> 
> > So there are really two parts to my question. 1. Am I thinking of all 
> > this in the right way ... that is, am I trying to do something 
> > unconventional (I don't want to) and is there a more standard way of 
> > providing daily builds to users. 
> 
> 'Sticking today's date on the packagename' sounds pretty conventional to 
> me.  
I can't tell you how confused I got over this. But my confusion was as
much about build philosophy as implementation. Tagging a build with a
tag that was not a CVS tag seemed wrong to me; but I no longer believe
that (for daily builds anyway).
> 
> > And 2) if my goal is a conventional one, how do people interact with 
> > these automatically generated files to get the job done?
> 
> Sorry, can't help you there. We write all our own tools for cvs 
> interaction.
> 
> 
> --
> David Fleck
> david.fleck at mchsi.com
> 
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug