Dup JENKINS-6999 and fixed in 1.3.1

I updated to Clearcase plug-in 1.3.1 and the problem remains.

2 file changes should have been detected here:

Started on Aug 6, 2010 2:46:05 PM
[hudson_gem_developer_view] $ /usr/atria/bin/cleartool pwv -root
/view/hudson_gem_developer_view
[workspace] $ /usr/atria/bin/cleartool lsview hudson_gem_developer_view

• hudson_gem_developer_view /b/uviews/agitarmr/hudson_gem_developer_view.vws
  [workspace] $ /usr/atria/bin/cleartool startview hudson_gem_developer_view
  [hudson_gem_developer_view] $ /usr/atria/bin/cleartool lshistory -all -since 6-aug-10.19:31:10utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -branch brtype:hudson_gem_developer_view -nco vobs/mxutil
  Done. Took 12 sec
  No changes

Without more input, I cannot help, the cleartool lshistory shows no change on the branch (hudson_gem_developer_view) and load rule you indicate (vobs/mxutil). It there anything I'm missing?

Something is wrong with the timestamps used to do the search.

Log states:
Started on Aug 6, 2010 4:01:05 PM
[hudson_gem_developer_view] $ /usr/atria/bin/cleartool pwv -root
/view/hudson_gem_developer_view
[workspace] $ /usr/atria/bin/cleartool lsview hudson_gem_developer_view

• hudson_gem_developer_view /b/uviews/agitarmr/hudson_gem_developer_view.vws
  [workspace] $ /usr/atria/bin/cleartool startview hudson_gem_developer_view
  [hudson_gem_developer_view] $ /usr/atria/bin/cleartool lshistory -all -since 6-aug-10.20:47:08utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -branch brtype:hudson_gem_developer_view -nco vobs/mxutil
  Done. Took 5.8 sec
  No changes

My local time is 4:01 PM (CST). The last build took place today at 10:47 AM (CST). It is searching for changes in the future (20:47:08utc+0000) and not finding any.

Notice also that the time stamp it is using to search with has changed since the last log I posted. It continues to search in the future with a changing date, instead of using the date of the last successful build.

• Polling is done using GMT time (+0000). CST is GMT-6 so it seems normal that it adds 6 hours to your time.
• Also, since 1.3, the polling time is recorded, so the polling is done since the last polling instead of the last build (only the first polling will poll with last build time)

When does the plug-in decide to poll with the last build time vs. the last build time? After reboot? After a new build?

Are the Clearcase pollings logged in a persistent file, or does each poll replace the last? It would good to see a history of the polling output to help debug the issue.

I can try some experiments to further pinpoint why the polling is failing.

I think it is risky to store the polling time vs. using the last successful build time. If something fails (like I am experiencing) the polling will never work again for those changes.

For each build, we store a SCMRevisionState in the build object (serialized inside jobs/<name>/builds/<build-timestamp>/build.xml

This SCMRevisionState is provided during the polling operation by hudson core. The polling generates a new SCMRevisionState that will be provided to the next polling.
However, I don't know whether this object is actually persisted. This logic is handled by Hudson Core, not by the plugin. The plugin decides what to put in the SCMRevisionState and how to use it.

On your side, I advise you to check if there isn't a timestamp inconsistency between your different machines (clearcase server and hudson server for instance)

I am attaching the build.xml from the last successful build. After reboot of the Hudson server, it did not use the time (or date) from the build.xml to look for changes. It didn't even try to use the lshistory command. Here is what it did:

Started on Aug 9, 2010 10:46:15 AM
[hudson_gem_developer_view] $ /usr/atria/bin/cleartool pwv -root
/view/hudson_gem_developer_view
[workspace] $ /usr/atria/bin/cleartool lsview hudson_gem_developer_view

• hudson_gem_developer_view /b/uviews/agitarmr/hudson_gem_developer_view.vws
  [workspace] $ /usr/atria/bin/cleartool startview hudson_gem_developer_view
  Done. Took 3.7 sec
  No changes

Do you specify any load rule for your job? If none is specified, the plug-in currently doesn't try to call lshistory. Maybe the plug-in behaviour should be changed to check for all paths inside the view root if no load rule is specified.

Hi,

I think I know what the problem is:

/usr/atria/bin/cleartool lshistory -all -since 6-aug-10.19:31:10utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -branch brtype:hudson_gem_developer_view -nco vobs/c

has wrong vob-path.

Should be:

/vobs/mxutil

I will check the code an see if it is easy to fix.

br,

//mike

Is there a workaround for it or are a solution on the way? I tried fixing it my self but I's to many new things for me to handle at the moment.

Hi,

I have looked at the one test case that where viewpath is changed to filepath. What is the relevance of this line:

List<ClearCaseChangeLogEntry> entries = action.getChanges(new Date(), "IGNORED", new String[]

, new String[]

);
assertEquals("Number of history entries are incorrect", 1, entries.size());
ClearCaseChangeLogEntry entry = entries.get(0);
assertEquals("File path is incorrect", "/vobs/Tools/framework/util/QT.h", entry.getElements().get(0).getFile());
}

Hi,

> List<ClearCaseChangeLogEntry> entries = action.getChanges(new Date(), "IGNORED", new String[]

, new String[]

);
> Is is a viewpath that is unrelated to what is defined in cleartool command.

It is unimportant what is the last path, since lshistory is not actually called in the testcase. Call to lshistory will be replaced by Expectations object, which will return value as specified (regardless of arguments - see all those with(any(...))). What this test does is checking that viewpath is removed from lshistory output (so that "/view/ralef_0.2_nightly/vobs/Tools/framework/util/QT.h" is converted to "/vobs/Tools/framework/util/QT.h").

> Also I can see that getChanges() is used in test code only but not in prod. code. Is this method replaced?

No, it isn't. It is called in AbstractClearCaseScm.saveChangeLog() which in turn is called in AbstractClearCaseScm.checkout().

Hi,

Thanks for pointing it out. Do you have a cc installation on Hudson? Since I do not have access to clearcase and Hudson at the moment.
My idea is now simply to add some trace in ClearToolExec for lshistory since I could see that vob-path is missing a / at the beginning.
I want to print out the following parameters and see what they are set to:

• viewPath
• filePath
• path

Can I add trace and send new hpi file so anyone can capture the trace?

br,

//mike

Hi,

vob path has initial / stripped by design. You see, vobs are not always available at root directory, you are probably tempted to think about vobs through the dynamic view which is set. However, the same vob could be available as /vobs/product in set dynamic view, as /view/some_view/vobs/product in dynamic view which is not set or as /usr/raspy/snapshots/snapshot_view/vobs/product in some snapshot view. Therefore what the plugin does is entering view path and then running lshistory for relative path (without /) vobs/product. Depending on configuration (dynamic/snapshot view and path) the working directory will be different, but the lshistory call can be the same.

See the console log that after 'cleartool startview' command, the current directory is no longer [workspace] when running lshistory.

I could make use of your trace plugin if you wish, but if its purpose is to check why / is stripped, I tell you now: it's by design

Best regards,
raspy

Hi,

ok so you are saying that vob path has the / removed. And when the lshistory is executed is uses working directory (depending on dynamic or snapshot) and the stripped vobpath.
Then ignore my above suggestion.

br,

//mike

On my instance it doesn't even try to run lshistory:

Started on Apr 11, 2012 2:16:16 PM
[jenkins_psd48_Inspect_and_Analyze_jenkins] $ cleartool pwv -root
[Inspect_and_Analyze] $ cleartool lsview jenkins_psd48_Inspect_and_Analyze_jenkins
Done. Took 0.14 sec
No changes

Is this plugin still being actively developed? This is a large issue and hasn't been updated in a while.