Cobalt Edge

After getting another request for my Perforce implementation for CruiseControl.rb, I've put it up on GitHub (cruisecontrolrb_perforce), and also updated my previous blog entry on the subject.

Just note, I haven't used this since August 2007, so use at your own risk :)

I'm starting to convert to Capistrano 2. We use Perforce, and I've found a simple typo/bug in Capistrano 1.99.1. The fix is simple:On line 57 of recipes/deploy/scm/perforce.rb, change the use of "revno" to "rev_no".

Now, the question is, where is the Capistrano bug DB, or where/how do I submit this to them?

I reported this to the mailing list, and Jamis has already checked in the fix in SVN. Capistrano lives in the Rails Trac.

While I haven't had a chance to clean up the code, folks have asked for it, so I'm making my Perforce implementation for CruiseControl available. There are some important notes:

• You need to set up your project manually, you can't do an "add" via CruiseControl.
• Some work needs to be done on the text retrieval for checkin messages, and how that's displayed on the CC.rb results pages.

To install/use it:

• Put the perforce.rb file into your cruisecontrol/app/models directory.
• Manually setup your project:


• Create a directory under the cruisecontrol/projects directory.
• Place a cruise_config.rb file in it. It should contain something like the following in order to use Perforce:
  

Project.configure do |project|# Use Perforce for source controlproject.source_control = Perforce.new(:port => 'your.perforce.server:1666',:clientspec => 'clientspec-for-cruisecontrol',:user => 'buildusername',:password => 'builduserpassword',:path => '//depot/path/to/your/rails/app/...')end

• Sync your code once.
• Fire up CruiseControl, and let the games begin.

Update: I've now given this an official home on GitHub. See the cruisecontrolrb_perforce project there. Fork at will, and please do send me Pull requests if you enhance the code, or at least tell me about your version, and I'll put that in the README or on the wiki, etc.

I got the Perforce support for CruiseControl.rb working this evening. I haven't done extensive tests yet, but seems to be going ok. I need to polish up a few bits, and then I'll post it (as well as submit a patch to the CruiseControl.rb project).

I'm working through this with Perforce tech support right now, but wondering if anyone else has seen this (since they didn't seem to know if it off-hand and it seems pretty significant)...

If I use the "-R" flag with Perforce commands, to get the output as Marshaled Ruby, with some commands, I only get the first file or item back. Specifically I'm seeing this with "sync" and "changes" commands. For example:

p4 -R sync
p4 -R changes -m 10

I am consuming these with code similar to:

Marshal.load(`p4 -R sync`)

I'm using Ruby 1.8.6 from MacPorts, on a MacBook Pro running MacOS X 10.4.9, and Perforce client "P4/MACOSX104X86/2006.2/112639 (2006/12/14)".

Update: Turns out that the output is still individual lines, but where the lines are marshalled Ruby. So, you simply need to process each line, with something like:

CMD="p4 -R sync"IO.popen(CMD, "rb") do |file|  while not file.eof    hash = Marshal.load(file)    synced_files << hash['data']  endend

Tonight I'm doing a quick bit of hacking to see if I can implement Perforce support for CruiseControl.rb. It looks promising, but we'll see. Perforce and SVN are quite different beasts. One cool thing though, Perforce has a -R flag to all commands that say to return the output as marshalled Ruby (they also have this for Python). This is very handy when writing scripts.

Also, if someone has already done this (i.e. my Google searches for it were too feeble), please let me know!

I'm a big TextMate user. We're also a Perforce shop. TextMate has a P4 bundle, and it works great, but it's main problem is that it has minimal knowledge of your P4 settings, and certainly doesn't handle multiple P4 clients or depots. For example, I have a few different clientspecs I work with, and the server, port, clientspec, etc. all differ. So, it's not feasible to use a single .p4config file, or set the values in TextMate or globally in the environment. This makes using the P4 bundle essentially impossible for all but whichever one you pick as your main clientspec.

To alleviate this, and based on how I organize my code on my machine, I wrote a simple little script that is what I set the "TM_P4" textmate environment variable to. This script knows that all my code is kept in subdirectories off my ~/Code directory. So, I then stash specific .p4config files at the root of each of these as needed, and the script looks for those based on the currently open file, and sets that for the P4 settings. This seems to work well. Here's the script in case it's useful to you:

#!/bin/sh## Script to run p4 commands in TextMate, and set the P4 variables# depending on the location of the file being operated on.# Where all my code livesCODE_PATH="${HOME}/Code/"# figure out the Code subdirectory for the current file in TextMateP4_CONFIG_PATH=${TM_FILEPATH##$CODE_PATH}P4_CONFIG_PATH=${P4_CONFIG_PATH%%/*}# Reconstitute as path to potential config fileP4_CONFIG_FILE="${CODE_PATH}${P4_CONFIG_PATH}/.p4config"# if dir contains a .p4config, set P4CONFIG to thatif [ -f $P4_CONFIG_FILE ]; then export P4CONFIG="$P4_CONFIG_FILE"else export P4CONFIG="~/.p4config"fi# now do p4/usr/local/bin/p4 $*