I've installed and started working with build 1382. I have some questions and some comments.
First is about using a different JDK than is used for the build agent. I brought this up before (http://www.intellij.net/forums/thread.jspa?threadID=222959&tstart=15) and have followed the jira issue (http://www.jetbrains.net/jira/browse/TW-307) which says it is fixed in 1382, but I have been unable to get everything set correctly to work. I edited the config by hand, set up the as described (and in a variety of ways as not described) and none of them seem to work quite right. The only change I see from the log is that it is trying to use "java" instead of /usr/java/jdk1.5.0/bin/java", which is what I have JAVA_HOME set to on the server for running the agent.
I tried adding:
in the project-config.xml and in buildAgent.properties:
But this didn't seem to work. I tried lots of different variations, though none of them seemed to do the trick. I even tried to do this explicitly (type 2 from the jira issue) and had:
but this did not work, either.
The first version is what I want, since we have 1.4 JDKs in different places on different machines (and different versions), but I was just trying to get either to work.
As I mentioned, we do have JAVA_HOME set, to get the agent working and the java in the path is not the 1.4.2 version.
Enough about that. We have several top level CVS modules for most applications. We bundle these into a CVS alias so that we get both the common modules and the application specific modules through one CVS "project". Using this works well in TeamServer if I just pass the project alias. So for example, we'd have the top level modules:
And these are all contained in the CVS alias app1. We might also have:
And these are contained in CVS alias app2. If we use "app1" and "app2" in the configuration, we end up with all these modules at the same level. The problem is that in general, the apps are being built against a tag or branch of common1 and common2, so I want to do a checkout of:
app1a - HEAD
app1b - HEAD
common1 - REL1
common2 - REL1
And have them all at the same directory level. I know there was an example shown at one point that showed working with branches, but I can no longer find it, nor do I recall if it addressed this. The FAQ doesn't seem to cover branching in any detail. Can you give me some info on how to accomplish the above?
Also along these lines, would it necessarily be the case that we would have to create separate toplevel projects for each variation of branches. Say I wanted to have a build with the previous example and one with:
app1b - HEAD
app1b - HEAD
common1 - REL1_1
common2 - REL1_1
Do they need different projects? Is there a way to group these projects somehow, as they are closely related as opposed to a build for app2.
A couple of comments. It would be nice to see the run time of each build on the viewType.html?buildTypeId=Apex_Build page. The reason being that it allows one to classify the failures to some extent since there is not necessarily any information other than "Failure" under the status (the only exception being "Tests failed:" as far as I can see). If I see a whole lot of builds listed and I have the build time available, I can make a reasonable estimate of which one made it furthest and which one failed immediately. The immediate failure is not likely of as much interest as the one which made it further, unless it is the most recent build.
Another question. In cruisecontrol, it is possible to set up a project so that it gets requeued after a failure even if thee haven't been additional checkins. This is our preferred setting, as we occasionally have transient failures which clear up with just a rebuild. Is there a way to set this?
We started using MySQL as the backend. It seems to work much better. Is this configuration preferred over hsql?
I notice that the "log_messages" table is growing very quickly. Is it cleaned up through the "Data Cleanup Policy" process? I do like the policy set up. It is fairly simple, but covers most of what I want. I currently do something slightly different in CC, which is successful builds for a month and failed builds for a week, but I think this may work for me just as well. How does it work if you have a policy for "All" and then one for a specific configuration?
It strikes me that having the CVS repository path as part of the hierarchy under the work directory is unnecessary and since it needs to be added to the Artifacts paths and Build file path, you end up with a lot more typing than necessary. From the example above, I'd think:
would be sufficient, rather than:
For that matter, I would think:
would be sufficient and most likely the more common usage and that if for some reason, an absolute path is needed, it should be easy enough to pick up the leading '/' to know not to work relative to the work directory.
I'm still a bit hazy on "Properties" vs. "environment" variables and how both end up used in the build.
Pausing projects is a bit difficult as it is a few levels in. It would be nice to have the projects page offer both "Run" and "Pause" buttons.
It would be nice to be able to create administrators for particular projects, just as it is possible to set a user to view particular projects.
It would be nice to be able to do some management of the build agents from a centralized spot. Say disabling them, setting them to run at certain times of the day.
More ability to configure the Projects view would be nice. Things such as filtering out successful builds and/or broken builds with someone taking responsibility. A collapse all for builds within a project. A top level collapse for a project which shows some metrics for that project.
I think that is probably well more than enough for now. Hope I wasn't too rambling.
It's coming along very well. I hope within the next build or two to start running TS in parallel with CC.