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

Radio buttons in the warnings plugin are deselected when the Flexible Publish plugin is installed

    Details

    • Similar Issues:

      Description

      After installing the flexible-publish plugin, the Publishers of some jobs get corrupted on save.

      E.g. I have a WarningsPublisher in my job with the following serialization:

      <publishers>
          <hudson.plugins.warnings.WarningsPublisher>
            <healthy></healthy>
            <unHealthy></unHealthy>
            <pluginName>[WARNINGS] </pluginName>
            <defaultEncoding></defaultEncoding>
            <canRunOnFailed>false</canRunOnFailed>
            <useDeltaValues>false</useDeltaValues>
            <thresholds>
              <unstableTotalAll></unstableTotalAll>
              <unstableTotalHigh></unstableTotalHigh>
              <unstableTotalNormal></unstableTotalNormal>
              <unstableTotalLow></unstableTotalLow>
              <failedTotalAll></failedTotalAll>
              <failedTotalHigh></failedTotalHigh>
              <failedTotalNormal></failedTotalNormal>
              <failedTotalLow></failedTotalLow>
            </thresholds>
            <shouldDetectModules>false</shouldDetectModules>
            <dontComputeNew>true</dontComputeNew>
            <parserConfigurations/>
            <consoleLogParsers>
              <string>Java Compiler</string>
            </consoleLogParsers>
          </hudson.plugins.warnings.WarningsPublisher>
      

      After installing the flexible-publish plug-in, I get the following result when saving the configuration. Seems that there is an interaction between these plug-ins.

      <publishers>
          <hudson.plugins.warnings.WarningsPublisher>
            <healthy></healthy>
            <unHealthy></unHealthy>
            <thresholdLimit>low</thresholdLimit>
            <pluginName>[WARNINGS] </pluginName>
            <defaultEncoding></defaultEncoding>
            <canRunOnFailed>false</canRunOnFailed>
            <useDeltaValues>false</useDeltaValues>
            <thresholds>
              <unstableTotalAll></unstableTotalAll>
              <unstableTotalHigh></unstableTotalHigh>
              <unstableTotalNormal></unstableTotalNormal>
              <unstableTotalLow></unstableTotalLow>
              <failedTotalAll></failedTotalAll>
              <failedTotalHigh></failedTotalHigh>
              <failedTotalNormal></failedTotalNormal>
              <failedTotalLow></failedTotalLow>
            </thresholds>
            <shouldDetectModules>false</shouldDetectModules>
            <dontComputeNew>true</dontComputeNew>
            <parserConfigurations/>
            <consoleLogParsers>
              <string>Java Compiler</string>
            </consoleLogParsers>
          </hudson.plugins.warnings.WarningsPublisher>
      

      The following tag is removed:

       <thresholdLimit>low</thresholdLimit>
      

      I have no idea what is causing that problem. Maybe the reason is something deep in core or in my analysis plug-ins. I need to attach a debugger to our server...

      Any ideas? What exactly is the flexible publisher doing in Jenkins core? Is it intercepting the publishers somehow?

      Interestingly, the problem has been reported with another simpilar plug-ins too: the template project.

      Here some related issues: JENKINS-8185, JENKINS-12182.

        Attachments

          Issue Links

            Activity

            Hide
            drulli Ulli Hafner added a comment -

            After removing the flexible-publisher and run-condition plugin, everything works fine again.

            Show
            drulli Ulli Hafner added a comment - After removing the flexible-publisher and run-condition plugin, everything works fine again.
            Hide
            bap bap added a comment -

            Hi Ulli,
            Flexible Publish does not do anything interresting in core - it just registers itself as a publisher and then holds a list of publishers to be invoked when it is.

            The reason that thresholdLimit is not persisted is because for some reason, when Flexible Publish (and some other plugins - JENKINS-8185 was created nearly a year before Flexible Publish was written) are installed, no radio button for Health priorities is selected and therefore not sent in the JSON object when the page is saved.

            The html input element in the page source has it "checked", but FF does not show it as selected - selecting it will submit the page correctly.

            The Flexible publish plugin is really quite ordinary in plugin terms and does not introduce any javascript or anything else I can think of that would change the way that Firefox is behaving.

            Can you think of anything in Warnings or Analysis Core that could be causing this?

            Show
            bap bap added a comment - Hi Ulli, Flexible Publish does not do anything interresting in core - it just registers itself as a publisher and then holds a list of publishers to be invoked when it is. The reason that thresholdLimit is not persisted is because for some reason, when Flexible Publish (and some other plugins - JENKINS-8185 was created nearly a year before Flexible Publish was written) are installed, no radio button for Health priorities is selected and therefore not sent in the JSON object when the page is saved. The html input element in the page source has it "checked", but FF does not show it as selected - selecting it will submit the page correctly. The Flexible publish plugin is really quite ordinary in plugin terms and does not introduce any javascript or anything else I can think of that would change the way that Firefox is behaving. Can you think of anything in Warnings or Analysis Core that could be causing this?
            Hide
            bap bap added a comment -

            It would appear that the dropdownDescriptorSelector is introducing another instance of the plugin view into the page even though the form elements are not visible in the page source (and the Warnings Publisher has not been selected). This means that the radio names and values are duplicated.

            Changing the radios in health.jelly to the following will give the radios the expected behaviour.

             
            <f:entry title="${%Health priorities}" description="${%description.health.priorities}">
              <j:invokeStatic var="pfx" className="java.lang.System" method="currentTimeMillis"/>
              <f:radio name="${pfx}.thresholdLimit" value="high" checked="${instance.thresholdLimit == 'high'}" title="${%Only priority high}"/>
              <f:radio name="${pfx}.thresholdLimit" value="normal" checked="${instance.thresholdLimit == 'normal'}" title="${%Priorities high and normal}"/>
              <f:radio name="${pfx}.thresholdLimit" value="low" checked="${(instance == null) ? 'true' : instance.thresholdLimit == 'low'}" title="${%All priorities}"/>
            </f:entry>
            

            The above would not be guaranteed to work (based on time), and a better approach would be to replace the pfx with a j:var which gets an increasing number from the descriptor. The number only needs to be unique during a single request.

            Show
            bap bap added a comment - It would appear that the dropdownDescriptorSelector is introducing another instance of the plugin view into the page even though the form elements are not visible in the page source (and the Warnings Publisher has not been selected). This means that the radio names and values are duplicated. Changing the radios in health.jelly to the following will give the radios the expected behaviour. <f:entry title= "${%Health priorities}" description= "${%description.health.priorities}" > <j:invokeStatic var= "pfx" className= "java.lang.System" method= "currentTimeMillis" /> <f:radio name= "${pfx}.thresholdLimit" value= "high" checked= "${instance.thresholdLimit == 'high' }" title= "${%Only priority high}" /> <f:radio name= "${pfx}.thresholdLimit" value= "normal" checked= "${instance.thresholdLimit == 'normal' }" title= "${%Priorities high and normal}" /> <f:radio name= "${pfx}.thresholdLimit" value= "low" checked= "${(instance == null) ? 'true' : instance.thresholdLimit == 'low' }" title= "${%All priorities}" /> </f:entry> The above would not be guaranteed to work (based on time), and a better approach would be to replace the pfx with a j:var which gets an increasing number from the descriptor. The number only needs to be unique during a single request.
            Hide
            drulli Ulli Hafner added a comment -

            I see, that would solve the problem for my plug-ins.

            Isn't there a better solution? Your solution requires that every plug-in using a radiobox (maybe there are other problematic fields) need to create such unique ids. This is not transparent for plug-in developers and hard to spot (it took me quite a couple of months to identify the actual cause of that bug). Do you have a good idea for that problem?

            Show
            drulli Ulli Hafner added a comment - I see, that would solve the problem for my plug-ins. Isn't there a better solution? Your solution requires that every plug-in using a radiobox (maybe there are other problematic fields) need to create such unique ids. This is not transparent for plug-in developers and hard to spot (it took me quite a couple of months to identify the actual cause of that bug). Do you have a good idea for that problem?
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: bap2000
            Path:
            src/main/java/org/jenkins_ci/plugins/flexible_publish/ConditionalPublisher.java
            src/main/resources/org/jenkins_ci/plugins/flexible_publish/ConditionalPublisher/config.jelly
            http://jenkins-ci.org/commit/flexible-publish-plugin/e1ba67f1635ec9986fddc5fd76c6462c059d5ef7
            Log:
            [FIXED JENKINS-12692] Choose the Artifact Archiver as the default publisher to play (a little) nicer with Warnings

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: bap2000 Path: src/main/java/org/jenkins_ci/plugins/flexible_publish/ConditionalPublisher.java src/main/resources/org/jenkins_ci/plugins/flexible_publish/ConditionalPublisher/config.jelly http://jenkins-ci.org/commit/flexible-publish-plugin/e1ba67f1635ec9986fddc5fd76c6462c059d5ef7 Log: [FIXED JENKINS-12692] Choose the Artifact Archiver as the default publisher to play (a little) nicer with Warnings
            Hide
            bap bap added a comment -

            So, racking my brain as to why the Flexible Publish plugin affected the Warnings publisher when the Promoted Builds Plugin did not, I realized that whilst the views for the describables were lazily loaded, the default, or if not specified, first in the list was loaded in the background - even when the plugin containing the descriptor list was not enabled!

            I have defaulted the conditional publisher to run the Artifact archiver, which means that by default there will not be a second instance of the warnings view on the page.

            I will look into the radio names and some other issues with warnings when I can get a fresh clone of the analysis-core tests to pass.

            Show
            bap bap added a comment - So, racking my brain as to why the Flexible Publish plugin affected the Warnings publisher when the Promoted Builds Plugin did not, I realized that whilst the views for the describables were lazily loaded, the default, or if not specified, first in the list was loaded in the background - even when the plugin containing the descriptor list was not enabled! I have defaulted the conditional publisher to run the Artifact archiver, which means that by default there will not be a second instance of the warnings view on the page. I will look into the radio names and some other issues with warnings when I can get a fresh clone of the analysis-core tests to pass.
            Hide
            drulli Ulli Hafner added a comment -

            Ok, thanks for fixing that!

            Show
            drulli Ulli Hafner added a comment - Ok, thanks for fixing that!

              People

              • Assignee:
                bap bap
                Reporter:
                drulli Ulli Hafner
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: