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

Races / corruption on revision.txt in pipeline-parallel

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None

      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.

          [JENKINS-58068] Races / corruption on revision.txt in pipeline-parallel

          Andreas Ringlstetter created issue -
          Andreas Ringlstetter made changes -
          Link New: This issue is related to JENKINS-39968 [ JENKINS-39968 ]
          Andreas Ringlstetter made changes -
          Description Original: 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:

          {code:java}
              <org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState plugin="workflow-scm-step@2.9">
                <revisionStates>
                  <entry>
                    <string>svn http://redacted/trunk&lt;/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&lt;/string>
                          <long>12362</long>
                        </entry>
                      </revisions>
                    </hudson.scm.SVNRevisionState>
                  </entry>
                </revisionStates>
              </org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState>
          {code}

          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.
          New: 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:

          {code:java}
              <org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState plugin="workflow-scm-step@2.9">
                <revisionStates>
                  <entry>
                    <string>svn http://redacted/trunk&lt;/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&lt;/string>
                          <long>12362</long>
                        </entry>
                      </revisions>
                    </hudson.scm.SVNRevisionState>
                  </entry>
                </revisionStates>
              </org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState>
          {code}

          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.
          Andreas Ringlstetter made changes -
          Link Original: This issue is related to JENKINS-39968 [ JENKINS-39968 ]
          Andreas Ringlstetter made changes -
          Description Original: 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:

          {code:java}
              <org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState plugin="workflow-scm-step@2.9">
                <revisionStates>
                  <entry>
                    <string>svn http://redacted/trunk&lt;/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&lt;/string>
                          <long>12362</long>
                        </entry>
                      </revisions>
                    </hudson.scm.SVNRevisionState>
                  </entry>
                </revisionStates>
              </org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState>
          {code}

          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.
          New: 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:

          {code:java}
              <org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState plugin="workflow-scm-step@2.9">
                <revisionStates>
                  <entry>
                    <string>svn http://redacted/trunk&lt;/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&lt;/string>
                          <long>12362</long>
                        </entry>
                      </revisions>
                    </hudson.scm.SVNRevisionState>
                  </entry>
                </revisionStates>
              </org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState>
          {code}

          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.
          Ivan Fernandez Calvo made changes -
          Assignee Original: Ivan Fernandez Calvo [ ifernandezcalvo ]

            Unassigned Unassigned
            ext3h Andreas Ringlstetter
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: