Absent Member.
Absent Member.

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.

Computer /var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle... attempt Computer /var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle... ok

On the second build, the file is deleted and checked out again.

Computer Deleted File: /var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle Computer /var/lib/jenkins/jobs/pharmanet-testdb/workspace/components/DMADMIN/build.gradle... attempt Computer /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?



1 Reply
Micro Focus Expert
Micro Focus Expert

RE: Jenkins Plug-in file status problem

Hi Paulo,

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.

Take care


The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.