Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-58068

Races / corruption on revision.txt in pipeline-parallel

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When used in a pipleine parallel block, the subversion plugin suffers from raceconditions 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="subversion@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. Assuming it is only written to once per build may be somewhat fitting to Freestyle projects, but is unsuited for pipeline projects.

        Attachments

          Activity

          There are no comments yet on this issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              ext3h Andreas Ringlstetter
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: