| In the scope of JENKINS-39968, the subversion plugin suffers from additional races due to the dependency on the "revision.txt" file as part of the checkout and change log computation process. Unsynchronized access to "revision.txt" causes `SubversionChangeLogBuilder ` to fail spuriously, as the file may be written to concurrently by other running checkout processes. The final "revision.txt" eventually reaches a stable state where it only contains the revision of the last "checkout" step, but in the process `SubversionChangeLogBuilder` has failed to record changes repeatedly (bailout with "No revision found for ....") and the "build.xml" is corrupted and contains fragments like the following:
<org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState plugin="workflow-scm-step@2.9">
<revisionStates>
<entry>
<string>svn http://redacted/trunk</string>
<hudson.scm.SVNRevisionState plugin="subve...@2.12.1">
<revisions>
<entry>
<string>ed/trunk</string>
<long>16122</long>
</entry>
<entry>
<string>svn http://redacted/trunk</string>
<long>12362</long>
</entry>
</revisions>
</hudson.scm.SVNRevisionState>
</entry>
</revisionStates>
</org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState>
In summary:
- Unsafe reads from "revision.txt" which contains data from parallel checkout processes
- Lost writes to "revision.txt" from previous checkout steps in the same build, with unstable results
While producing "revision.txt" as a side product of the build process may be desired to keep as a side effect, using it internally means state between `SubversionSCM` instances in the same build is shared in an unsafe way. |
