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

invalid svn:externals warnings are swallowed silently and ignored during checkout

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • subversion-plugin
    • None
    • JDK 1.6.0_20, Hudson 1.355, Subversion plugin 1.16

      I noticed the current handling of broken svn:externals in the hudson subversion plugin is wrong.

      this is the behaviour of a checkout with a valid svn:externals property:
      Build #1 (02-May-2010 07:18:20)
      add description Revisions
      https://localhost/svn/test/wibble : 135
      https://localhost/svn/test : 136
      No changes.

      Console Output
      Started by user admin
      Checking out https://localhost/svn/test
      A bar
      A bar/hello.txt
      A wibble
      A wibble/bye.txt
      Fetching 'https://localhost/svn/test/wibble' at -1 into '/home/hudson/jobs/test/workspace/test/bar/wibble'
      A bar/wibble/bye.txt
      At revision 136
      At revision 136

      now I break the svn:externals property committing an invalid path:
      Build #2 (02-May-2010 07:21:27)
      add description Revision: 137
      Changes
      breaking the path of the svn external (detail)

      Console Output
      Started by user admin
      Checking out https://localhost/svn/digitalgold/test
      A bar
      A bar/hello.txt
      A wibble
      A wibble/bye.txt
      At revision 137

      As it can be seen there's no mention of any error during the checkout stage. When using the svn command at least there is a warning:
      svn co https://localhost/svn/test
      A test/bar
      A test/bar/hello.txt
      A test/wibble
      A test/wibble/bye.txt
      svn: warning: Error handling externals definition for 'test/bar/wibble':
      svn: warning: URL 'https://localhost/svn/test/wibble-broken' at revision 137 doesn't exist
      Checked out revision 137.

      I also wonder if it would be useful to provide an option in the Source Code Management Subversion section to fail the build immediately if there is an issue handling svn:externals definitions like in the case above.

      many thanks.

          [JENKINS-6415] invalid svn:externals warnings are swallowed silently and ignored during checkout

          lcantey added a comment - - edited

          I'm in agreement with the earlier posters that the priority should be elevated. Having no visible evidence of the failure and continuing the build makes it difficult to diagnose and can lead to misleading results. It wasn't noted above but credential issues show the same issue.

          lcantey added a comment - - edited I'm in agreement with the earlier posters that the priority should be elevated. Having no visible evidence of the failure and continuing the build makes it difficult to diagnose and can lead to misleading results. It wasn't noted above but credential issues show the same issue.

          Chris Z added a comment -

          As abarbieri and lcantey said, weight of this issue should be changed. It took me some couple of hours to investigate what was the reason of change in project code without result in the output binary. Build should never be marked as a successful when error in svn checkout occurs.

          Chris Z added a comment - As abarbieri and lcantey said, weight of this issue should be changed. It took me some couple of hours to investigate what was the reason of change in project code without result in the output binary. Build should never be marked as a successful when error in svn checkout occurs.

          evernat added a comment -

          Hi all,
          Is it reproduced with recent versions of the subversion plugin and of Jenkins?

          evernat added a comment - Hi all, Is it reproduced with recent versions of the subversion plugin and of Jenkins?

          Chris Z added a comment -

          Yes, still exist. Last time I made fix for this with: https://github.com/jenkinsci/subversion-plugin/pull/9. Now the svnkit changed and I don't have time to check what should be changed.

          Chris Z added a comment - Yes, still exist. Last time I made fix for this with: https://github.com/jenkinsci/subversion-plugin/pull/9 . Now the svnkit changed and I don't have time to check what should be changed.

          Dominik Ruf added a comment -

          Dominik Ruf added a comment - I crated a pull request https://github.com/jenkinsci/subversion-plugin/pull/50

          I'm seeing this on Jenkins 1.599 using subversion-plugin version 2.4.5 (can't use 2.5 due to JENKINS-27084).

          Rasmus Pedersen added a comment - I'm seeing this on Jenkins 1.599 using subversion-plugin version 2.4.5 (can't use 2.5 due to JENKINS-27084 ).

          Roland Stahn added a comment -

          I just noticed this behavior using "Jenkins ver. 1.651.3.1 (CloudBees Jenkins Enterprise 16.06)" with Subversion plugin 2.5.7.
          I am kinda shocked that this is a known issue for more than six years now, since I consider this behavior as not acceptable for a CI environment!
          We currently use Jenkins to actually check if a SVN project is consistent and its really a show-stopper to not notice broken externals.

          Roland Stahn added a comment - I just noticed this behavior using "Jenkins ver. 1.651.3.1 (CloudBees Jenkins Enterprise 16.06)" with Subversion plugin 2.5.7. I am kinda shocked that this is a known issue for more than six years now, since I consider this behavior as not acceptable for a CI environment! We currently use Jenkins to actually check if a SVN project is consistent and its really a show-stopper to not notice broken externals.

          I noticed this behaviour using "Jenkins ver. 1.625.1" with Subversion plugin 2.6.

          Gustavo Chaves added a comment - I noticed this behaviour using "Jenkins ver. 1.625.1" with Subversion plugin 2.6.

          Roland Stahn added a comment -

          Are there any plans to fix this behavior?

          Roland Stahn added a comment - Are there any plans to fix this behavior?

          Hello,

          Is there any workaround for this issue?
          Actually we have warnings in SVN checkouts and we need the build to break if it occurs.

          Sébastien RIBIERE added a comment - Hello, Is there any workaround for this issue? Actually we have warnings in SVN checkouts and we need the build to break if it occurs.

            recena Manuel Recena Soto
            abarbieri Andrea Barbieri
            Votes:
            12 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated: