1

My ci trigger works well as soon as I don't use clearfsimport. In the special case of clearfsimport. the ci trigger cannot find the file.

Here's the way I build the filename in my trigger:

my $filename = ( $ENV{'LOGNAME'} ? $ENV{'CLEARCASE_ROOT'} : '') .  $ENV{'CLEARCASE_PN'};

For both case (cleartool ci and clearfsimport, the file name is a local path to the file i.e L:\VobName\Path\file.txt.

I don't know two things:

  • How the trigger can open the file if I give to it a 'local path' that cannot be resolved on the server-side?
  • Why it still works with cleartool ci but not with clearfsimport

EDIT

Actually it seems the concerned files are removed by some program or script before the call to the CI trigger. After the execution of clearfsimport the concerned files are back there. This result that the trigger cannot open the file because it's missing. Does it mean CI triggers cannot work with clearfsimport?

nowox
  • 25,978
  • 39
  • 143
  • 293

2 Answers2

1

The clearfsimport (which I use here to import files), might work differently that a classic ci.

  • a checkin means: the file is here, checked out, and is checked in
  • a clearfsimport means: the file is not here yet, he is added (declared in the parent folder), and directly checked-in (the doc says "reads the specified file system source objects and places them in the target VOB"), then the parent folder is updated.
    So the check-in might occur directly in the vob, and not rely on actual pathname (CLEARCASE_PN).

Maybe you could try $ENV{'CLEARCASE_XPN'} (the extended pathname), to see if you can access the file that way (except you might need a dynamic view to access the content referenced by an extended pathname).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • unfortunately it doesn't work either with `$ENV{'CLEARCASE_XPN'}`. `clearfsimport` somehow removes the file before the trigger is called. I can see it if I output to `STDERR` the content of my concerned folder during the trigger's execution. – nowox Nov 04 '14 at 09:52
  • @coin are you using a snapshot or dynamic view? – VonC Nov 04 '14 at 10:04
  • I'm using both as you advised me before. A snapshot view as a working directory and a dynamic view to push files with clearfsimport. So clearfsimport operates on a dynamic view. – nowox Nov 04 '14 at 10:10
  • @coin ok. A dynamic view should be able to access the content of an extended path... if said path exists when the ci trigger is called (I supposed is is a post-op trigger, not a pre-op?) – VonC Nov 04 '14 at 10:13
  • Yes I think it's a post-op trigger because it is a modified comment trigger as I can read here: http://www.ibm.com/developerworks/rational/library/4311.html#t2 – nowox Nov 04 '14 at 10:22
1

Clearfsimport operates more or less like a "cleartool checkin -from" command.

So, as a result, you need to use the CLEARCASE_CI_FPN environment variable.

Something like this test (using Perl) should work:

$ccpn = $ENV{"CLEARCASE_PN"}; if (!(-e $ccpn)) { $ccpn = $ENV{"CLEARCASE_CI_FPN"}; if (!(-e $ccpn)) { printf("Cannot locate File being checked in!\n"); exit 1; } } open( INFILE,"< $ccpn");

This may not be the most straightforward way to handle it, but imports act differently because the file is not yet actually in the ClearCase repository when the trigger fires.

Brian Cowan
  • 1,048
  • 6
  • 7
  • Unfortunately, the `CLEARCASE_CI_FPN` act before the comparison with the destination repository. If I modify the file as I generally do with the regular trigger, I'll get a new version on ClearCase. – nowox Nov 12 '14 at 08:39
  • I'm a little confused by that. If you're modifying the file in a trigger, then you're almost guaranteed to get a "new version" on checkin. What are you trying to do in the body of the trigger anyway? – Brian Cowan Nov 12 '14 at 19:46