-
Bug
-
Resolution: Fixed
-
Major
-
Jenkins 1.536 + Jenkins CVS Plug-in 2.10 on OSX 10.7.5
This was initially reported as part of JENKINS-17965 but the fix for that issue did not fix this problem.
We have a matrix job that runs fine except that when the master does
that initial CVS update on the master prior to launching any of the matrix
builds on slaves, it gives a CVS "file was lost" error for every file in the
project.
The job is parameterized with a boolean named DELETE_WORKSPACE which is
set as the "Check parameter" for "Delete workspace before build starts" in
the Build Environment. If I set DELETE_WORKSPACE to true, the build runs
perfectly without any CVS errors which implies that my CVS authentication is
correct.
I tried running the CVS commands from the terminal window, and here's
what I see.
If I run the commands directly:
1) cvs checkout -P -d project project (this is what Jenkins does if DELETE_WORKSPACE is true)
2) cvs update -C -d -P project (this is what Jenkins does if DELETE_WORKSPACE is false)
Both CVS commands run fine.
If I let Jenkins run the first command by performing the build:
1) Run the Jenkins job with DELETE_WORKSPACE=true
2) cvs update -C -d -P project
During the cvs update, CVS gives me a bunch of warnings about locally modified files being moved to temporary files.
And if I do this:
1) Run the Jenkins job with DELETE_WORKSPACE=true
2) cvs status project
3) cvs update -C -d -P project
Then I don't get any warnings during the cvs update about locally modified files.
Michael Clarke suspects "something is going wrong with the way we manage the entries file."
[JENKINS-20188] cvs update produces "file was lost" errors
Chris Shearer Cooper
added a comment - 1. Nope, the jobs don't do anything strange to files in the workspace - they check files out (with "prune empty directories", "show all cvs output" and "force clean copy" options enabled), do a couple of CMake builds (one for the application and one for the unit tests), archive the artifacts, and publish the test results.
2. In my initial comments, when I say I ran "cvs status" or "cvs update", that's from the command line with the current directory set to the appropriate workspace.
3. We are up-to-date with the CVS server (which isn't saying much) - 1.12.13.
Chris Shearer Cooper
added a comment - 1. Nope, the jobs don't do anything strange to files in the workspace - they check files out (with "prune empty directories", "show all cvs output" and "force clean copy" options enabled), do a couple of CMake builds (one for the application and one for the unit tests), archive the artifacts, and publish the test results.
2. In my initial comments, when I say I ran "cvs status" or "cvs update", that's from the command line with the current directory set to the appropriate workspace.
3. We are up-to-date with the CVS server (which isn't saying much) - 1.12.13. Can you try running the build with 'force clean copy of files' unchecked, or install the snapshot at https://jenkins.ci.cloudbees.com/job/plugins/job/cvs-plugin/202/org.jenkins-ci.plugins$cvs/artifact/org.jenkins-ci.plugins/cvs/2.11-SNAPSHOT/cvs-2.11-SNAPSHOT.hpi , and see if that fixes your issue?
Chris Shearer Cooper
added a comment - Problem is solved using snapshot from build #202 - thanks! 
I need more details about your setup:
1. Are your jobs modifying CVS controlled files in the workspace, or changing the workspace structure at all?
2. If you complete a job then manually run the update command in the workspace, do you get warnings about lost files (your issue isn't clear on whether you ran this command in a post-build workspace, were letting Jenkins run it, or something else)
3. What version of CVS server are you running?
Thanks