Comments
Hey Marcus,
This is indeed a bug in Cruise 1.3.2. we hope to fix it in an upcoming version of Cruise.
If you specify the hostname (rather than 127.0.0.1) in your ProxyPass directive then you should get a somewhat better experience in that the URL would contain that hostname and not 127.0.0.1.
chris
It is not possible to change the default location for the cruise agent's working directory when running it out of the "Cruise Agent.app" directory. However it is possible to run the Cruise Agent directly from the jar file as described on this page:
If you do this then the agent will create a working directory (called 'pipelines') relative to the directory where you start the agent. So you could do this from another directory on your RAID drive. This can of course be any directory name, and in your case this will solve the second problem also.
(Copying the solution here from our support database for others wondering about this)
From the console log, "product-stable/18/VerificationBuild/1/BuildApplication-BuildUnitTests" running on SVN version 6263 has pipeline label "18" and "product-stable/3/Archive/6/ArchiveInstaller" running on SVN version 6213 has pipeline label "3" (Pipeline label is the identifier for a pipeline run and is the first number in the path). So, they actually are runs from 2 different pipeline instances which means they could be associated with different SVN versions.
You can navigate to the Pipeline Activity page (click on the pipeline name in the Current Activities page) in order to get the view of the pipeline instances and trigger the versions from there?
You are right about the BOM being the cause of this issue. We have already fixed it in the next version of Cruise.
We have checked this and it is a bug in Cruise 1.0 and Cruise 1.1. You can leave the workingDir out and it will do what you expect, which is to use the pipeline working directory.
chris
We do support multiple dependencies in Cruise 1.1, but the logic is ‘or’ not ‘and’. That is, pipeline C will be triggered if either Pipeline A Stage A or Pipeline B Stage B complete.
I’ve checked our help and the syntax is incorrect in the example in the managing dependencies section. Please accept our apologies for this documentation bug.
Please see this post: http://studios.thoughtworks.com/discussion/forums/13/topics/762
While we do want to improve the editing our users have told us that they want other features first. We are looking for feedback on what the most common editing tasks are so we can prioritize those – what do you do most often that you find painful in the current editor?
The syntax is :
<dependencies>
<depends stage="Build" pipeline="rf-core-continuous" />
</dependencies>Can you also check that the stage and pipeline names have the same capitalization, and also that the dependecies are defined on the dependent pipeline i.e. the one that you want triggered.
We are investigating allowing you to specify this working directory in a future version of Cruise. However in the meantime you could install the Agent in a different directory (e.g. C:\Cruise) to save on path length.
chris
This is caused by a missing dependency during installation. Cruise uses the unzip command during installation and if this command is not available then the install will fail and the server will not be able to start.
To validate that this is your issue, try running the unzip command. If ubuntu reports that it is not installed, this is your problem.
$ unzip The program 'unzip' is currently not installed. You can install it by typing: sudo apt-get install unzip -bash: unzip: command not found
To fix this issue:
Remove (purge) partly installed Cruise by running :
sudo dpkg -P cruise-server
Install unzip:
sudo apt-get install unzip
Re-install Cruise:
sudo dpkg -i cruise-server-1.1-5477.deb
For others facing this issue:
You can build java 1.5 projects with Java 1.6. In fact this is the recommended way to do it. If you use intellij then it is probably already doing this.
The way to do it is to set the source and target properties on your ant javac task
http://ant.apache.org/manual/CoreTasks/javac.htmlCopied from there:
source
Value of the -source command-line switch; will be ignored by all implementations prior to javac1.4 (or modern when Ant is not running in a 1.3 VM) and jikes. If you use this attribute together with jikes, you must make sure that your version of jikes supports the -source switch. By default, no -source argument will be used at all. Note that the default value depends on the JVM that is running Ant. We highly recommend to always specify this attribute. A default value for this attribute can be provided using the magic ant.build.javac.source property.target
Generate class files for specific VM version (e.g., 1.1 or 1.2). Note that the default value depends on the JVM that is running Ant. In particular, if you use JDK 1.4+ the generated classes will not be usable for a 1.1 Java VM unless you explicitly set this attribute to the value 1.1 (which is the default value for JDK 1.1 to 1.3). We highly recommend to always specify this attribute. A default value for this attribute can be provided using the magic ant.build.javac.target property.chris
Hey Thibault,
The current version of Java on MacOSX is “Java for Mac OS X 10.5 Update 2”. This is actually J2SE 6 aka Java 1.6. It is only available for 64bit intel Macs on Leopard (1.5). http://developer.apple.com/java/
There is an unofficial build of Java 1.6 for the Mac called soylatte that runs on older Macs and older operating systems. http://landonf.bikemonkey.org/static/soylatte/ licensed under the Java research license. I am not sure what the implications of this license are.
hope this helps,
chrisFYI restarting the agent service is necessary since it can’t pick up if the system environment changes after it was started. I’m not aware of any way to avoid this unfortunately.
We do this to support scenarios where the new Agents can be added with minimal configuration. Our requirement is that the Agent can run a build from Perforce when the only thing installed is the p4 client/workspace. In order to do this, Perforce creates its own p4 client/workspace that points towards the Agent sandbox.
Having said that, the agent will also honour any perforce environment variables that are defined in the environment. So you could specify all settings in the environment variables on the Agent machines. Be aware though that there is currently no way to tell the build tasks to build in a directory outside the sandbox.
It helps to know the way people want to use the perforce support, so please let us know what you usage patterns are like and we will try to address them.