Jenkins Plug-in file status problem
Hi, I'm looking for the cause of why the Jenkins plug-in (version 0.6.13 with SDK 14) is checking out a file again that had been checked out in a previous build but hasn't changed.
For example, on the first Jenkins build, the file is checked out by the plug-in.
/var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle... attempt /var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle... ok
On the second build, the file is deleted and checked out again.
Deleted File: /var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle /var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle... attempt /var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle... ok
The plug-in does this if the files status is 'MODIFIED', but the file itself hasn't changed so how is it determining that it has?
Our installation is a little funny. Originally our Unix 'gurus' installed Jenkins in /var/lib/Jenkins, but subsequently ran out of room in that filesystem so they moved everything to /space/jenkins, then used a symbolic link from /var/lib/jenkins -> /space/jenkins. This is the only thing that I can think of that might cause StarTeam's status repository to fail as it might be trying to compare the symbolic location with the physical location and treating them as different or something.
We will be looking to install the latest 0.8.1 plug-in along with SDK 15, but I'm skeptical that is the source of the problem.
Can you provide any insights into how the status repository works that might give us a clue as to how it seems to be deriving an improper file status?
RE: Jenkins Plug-in file status problem
The v 0.6.13 jenkins plugin is over 6 years old, and was owned by the open source community, written against the old starteam sdk namespace. To be absolutely honest, we have no idea how it was written, or by whom. MicroFocus took over the responsibility of ownership of the plugin two years ago, and since then put out successive releases, culminating in 0.8.1
This latest version uses the SDK's 'new' namespace CommandLine engine, so we rely upon a stock implementation of file checkout from our status repository.
>>trying to compare the symbolic location with the physical location and treating them as different or something
we did fix a bug in our checkout algorithms 2 months ago, that was related to symbolic links status calculation. depending upon the way 0.6.1 was written, it may well have been affected by this bug.
>>insights into how the status repository works
The status repository is stored in a folder structure on your local disk.
every file whose status is known is saved using its md5, size, last modification time, dot notation and view id.
these sync structures are then used to compare the file on disk with the status 'database' to determine whether the file is current, out of date, modified, etc. as a simple trivialization, a file on disk with a time stamp after the status db entry, and a different size (or md5), is considered Modified.
I would certainly recommend the upgrade to the 0.8.1 plugin and the 15.1 SDK, a patch release of the SDK/CPC is due out this coming Friday.