Comments

  • 1-10 of 10
  • Chris Turner
    posted March 25, 2009 in Go > Bug Reports

    Hi Julian,

    Here are the issues as I see it:

    • As far as we've been able to figure out, Cruise has no way to keep ssh (by way of git) from output the fingerprint verification request to sysout.
    • When Cruise is launched from the /etc/init.d script, it is run as a daemon. When ssh outputs the fingerprint request, it has no access to sysin. When you type "yes", you're actually running /usr/bin/yes; a command (as I just now discovered) will repeatedly type 'y' (man page)

    The best I can give you for a solution to this is to:

    • sudo su cruise
    • Fix the fingerprint issue: ssh github.com followed by yes when it asks about the fingerprint
    • Ensure you have a keypair that github knows about. Either:
      • Copy an existing private key file into /var/cruise/.ssh/
      • ssh-keygen while logged in as cruise. Make sure that the keyfile has no password. Also you'll need to add the public key to your github account.

    Hope this helps,

    Chris

  • Chris Turner
    posted December 15, 2008 in Go > Troubleshooting

    Hi Nick,

    Those 2 errors are from the same issue. For some reason, git clone isn’t working, which means the scheduler can’t check for modifications…

    What version of git are you using?

    In order to debug this, the easiest thing to do is set logging to debug (change the first line in config/log4j.properties from INFO to DEBUG) and look in the cruise-server.log to see what command arguments are being passed into git clone. I usually try running that command on my own to see what errors are occuring.

    If you want, you can email me your cruise-server.log file (with debug enabled) and I can try to debug it for you. My email address is cturner at thoughtworks.com

    Chris

  • Chris Turner
    posted October 3, 2008 in Go > General Discussion

    Hi there.

    I just double checked the code and you are exactly right as to the nature of the problem. We are, indeed, wrapping the target field in quotes. I’m going to file this as a bug.

    In the meantime, the work around is to use the exec task.

    Chris

  • Chris Turner
    posted August 25, 2008 in Go > General Discussion

    Will the source-code be checked out only when there is a modification? Or will forcing the build also check out the code?

    So there are two things here… Cruise Server and Cruise Agent. For SVN, the server will never check-out the code (for Mercurial it does).

    The agent will always check-out the source into a sandbox (Cruise Agent\pipelines) and run your nant script from there. It doesn’t matter if this is caused by a modification or forcing the build. They work the same.

    Once the code is checked-out, how do I access it?

    The <tasks> tag within the <job> tag are used for accessing your code. The current working directory is the root of your checked-out code, so you shouldn’t need to know where it is from a running your tests standpoint.

    Is it within the C:\Program Files\Cruise Agent\ directory?

    It will be checked out to C:\Program Files\Cruise Agent\pipelines\{pipelineName}

    Are there any task variable I can use to access this path?

    No. We just set the current working directory of all of the tasks (including the exec task) to be the root of the checked-out code.

    Can I hard-code a path instead of the default location for checking-out?

    There is currently no way to change where the agent checks out the code. We are looking into allowing this to be an option, but it’s not there yet.

    After compiling is complete, I know I can save it in the Artifacts within Cruise. Is there a sample config or explanation on how to get this done?

    Here is the help page dealing with publishing artifacts.

    After I save the binaries in Artifacts within Cruise, how does the next stage access the binaries?

    The answer to this is a little more involved. Look at my response here.

    As I mentioned earlier, I would like to run NUnit to run unit tests. Can this be accomplished with a nant buildfile? Would the job configuration be:

    <job name="RunUnitTests">
        <tasks>
            <nant buildfile="nant-file-for-running-unit-tests" 
                  target="target-for-running-unit-tests" />
        </tasks>
    </job>
    

    That looks right. The configuration reference for nant can be found here.

    Hope this helps! If you have any other questions, just let us know.

    Chris

  • Chris Turner
    posted August 24, 2008 in Go > Feature Requests

    Hey Pete,

    Initially the sub tabs of the Job detail page all worked that way. We actually found that for the normal case, this was really annoying for users. They would click back and forth between Modifications and Failures tabs and expect the back button on their browser to send them (in your example) back to the stage activity page. Also, the requirement was raised to be able to stay in the same sub tab as we are looking thru a jobs history.

    Good news, however. :) We just started playing a story to put a “link directly to this sub tab” link on each tab, so you can email from there. As a short-term workaround, however, all sub tabs (including ones created by you in the config file) have an anchor of #tab-(tabname) that will open that tab. For example, on one of our jobs we have a sub tab named “Emma”. The anchor is #tab-emma. Just add that to the end of a url you want to email somebody and that should send them to the correct tab.

    Hope this helps,
    Chris

  • Chris Turner
    posted August 24, 2008 in Go > Bug Reports

    Pete,

    If you see this happening again, could you let us know? I just took a look at the code, and I’m not able to find how that could have happened…

    Chris

  • Chris Turner
    posted August 24, 2008 in Go > Bug Reports

    Hey Pete,

    Thanks. That one slipped passed us. It should have read, “It’ll be there for 1.1, promise.” ;-)

    We’ll add this to the list of documentation fixes we need to take care of.

    Chris

  • Chris Turner
    posted August 14, 2008 in Go > Bug Reports

    Hi Chris,

    The issue here is that there is no way for us to XSD validate an XML partial. What we currently do is pull the information out of the XML snippit and load it into our domain object. Then we stream it out to XML (with XSD validation at this point). Any extra tags/attributes are ignored.

    The ultimate solution that we are intending in order to solve this is to create wizards with fully verifiable input boxes (potentially leaving the XML snippets for power users)

    Thanks,
    Chris

  • Chris Turner
    posted August 14, 2008 in Go > Troubleshooting

    The reason this is happening is due to RPM not knowing that you already have java 1.6 installed (since you installed it from source).

    We’ve decided that the default use case would assume 1.6 being installed by rpm, mostly because we can be assured of where it’s installed. If this is not the case (as in your situation) we have no consistent way to know where JAVA_HOME should point to. The way to handle this is to ignore deps when installing and change the /etc/default/cruise-[server|agent] file to point JAVA_HOME to the correct folder. (Which, it sounds like, you figured out on your own).

    Hope this helps,
    Chris

  • Chris Turner
    posted August 3, 2008 in Go > Feature Requests

    Hi Joseph,

    This is a really interesting idea… We’re definitely going to take a look at it. Right now, we’re thinking this would be more of a depends case than a material case, but with the same effect.

    Currently depends is for triggering a pipeline when another stage completes successfully. This sounds like more of an external depends.

    Chris