• Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Blocker Blocker
    • core, maven-plugin
    • None
    • Jenkins 2.108

      Hi,

      we did an upgrade from 2.103 to 2.108 today. After the update we noticed that some xUnit related jobs were failing.

      So we went ahead and tried to open the job configurations page and failed. We were and are unable to open job configuration pages. This seems to "only" affect Maven jobs for us, but we see no error logs or anything else that would give us a hint what the root cause of this error is.

      I already tried creating a fresh job, but this doesn't work as well.

       

      Any help is highly appreciated as this is basically blocking any work with Jenkins at the moment. It would also help if you could clarify if the xUnit step problem might be related or not.

       

      Cheers,

      Christoph

          [JENKINS-49625] Config pages of Maven jobs do no load

          Oleg Nenashev added a comment -

          It is not possible to say anything without startup logs

          Oleg Nenashev added a comment - It is not possible to say anything without startup logs

          oleg_nenashev Please find the log attached

          Christoph Dreis added a comment - oleg_nenashev Please find the log attached

          Christoph Dreis added a comment - - edited

          We're actually seeing a similar behavior as JENKINS-49630

          Yet, this seems to be unrelated to Bitbucket, but to a normal git setup.

          descriptorByName/hudson.plugins.git.UserRemoteConfig/fillCredentialsIdItems

          {code}

          updateListBox (select.js:4)
          (anonymous) (select.js:79)
          h (hudson-behavior.js:1304)
          refillOnChange (hudson-behavior.js:1319)
          (anonymous) (select.js:77)
          (anonymous) (behavior.js:111)
          (anonymous) (behavior.js:107)
          applySubtree (behavior.js:93)
          (anonymous) (select.js:269)
          setTimeout (async)
          (anonymous) (select.js:263)

          {code}

          Christoph Dreis added a comment - - edited We're actually seeing a similar behavior as JENKINS-49630 Yet, this seems to be unrelated to Bitbucket, but to a normal git setup. descriptorByName/hudson.plugins.git.UserRemoteConfig/fillCredentialsIdItems {code} updateListBox (select.js:4) (anonymous) (select.js:79) h (hudson-behavior.js:1304) refillOnChange (hudson-behavior.js:1319) (anonymous) (select.js:77) (anonymous) (behavior.js:111) (anonymous) (behavior.js:107) applySubtree (behavior.js:93) (anonymous) (select.js:269) setTimeout (async) (anonymous) (select.js:263) {code}

          Oleg Nenashev added a comment -

          Looks similar to JENKINS-49630

          Oleg Nenashev added a comment - Looks similar to JENKINS-49630

          The behaviour is very inconsistent. On some jobs I'm not even getting to the config page at all. On some I see the spinner as described above and in JENKINS-49630. The one where I can't see the page at all is actually a new Maven Job I tried to create in order to test things.

          Christoph Dreis added a comment - The behaviour is very inconsistent. On some jobs I'm not even getting to the config page at all. On some I see the spinner as described above and in JENKINS-49630 . The one where I can't see the page at all is actually a new Maven Job I tried to create in order to test things.

          I discovered the same problem with version 2.106. When updating to 2.107, the problem was solved but when going to 2.108 it was back again.

          Christian Orthmann added a comment - I discovered the same problem with version 2.106. When updating to 2.107, the problem was solved but when going to 2.108 it was back again.

          Ralph Goers added a comment -

          Please take a look at the workaround we found for JENKINS-49630.

          Ralph Goers added a comment - Please take a look at the workaround we found for JENKINS-49630 .

          I appreciate the workaround, rgoers. Yet, this doesn't seem to confirm that the root cause is actually in the XML file parsing. It only confirms that one could go back to 2.104.

          Christoph Dreis added a comment - I appreciate the workaround, rgoers . Yet, this doesn't seem to confirm that the root cause is actually in the XML file parsing. It only confirms that one could go back to 2.104.

          I don't know if it's related, but, as in JENKINS-49630 may be caused by an outdated plugin that try to parse some xml files, like the Violations plugin and so on.

          Mauro Ferratello added a comment - I don't know if it's related, but, as in JENKINS-49630  may be caused by an outdated plugin that try to parse some xml files, like the Violations plugin and so on.

          Indeed related, but can be closed as the root cause provided in JENKINS-49630 is in fact the Violations plugin.

          Christoph Dreis added a comment - Indeed related, but can be closed as the root cause provided in JENKINS-49630 is in fact the Violations plugin.

            Unassigned Unassigned
            christophdreis Christoph Dreis
            Votes:
            1 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: