[JENKINS-12692] Radio buttons in the warnings plugin are deselected when the Flexible Publish plugin is installed - Jenkins Jira

XML

Word

Printable

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Blocker
Resolution: Fixed
Component/s: flexible-publish-plugin
Labels:
None

Similar Issues:

Show

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

is related to

JENKINS-12182 Publisher - Code Analysis - NullPointerException

Resolved

JENKINS-8185 Exception in WarningsPlugin

Closed

Activity

Ascending order - Click to sort in descending order

Ulli Hafner added a comment - 2012-02-10 09:24

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

Ulli Hafner added a comment - 2012-02-10 09:24 After removing the flexible-publisher and run-condition plugin, everything works fine again.

bap added a comment - 2012-02-12 13:50

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?

bap added a comment - 2012-02-12 13:50 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?

bap added a comment - 2012-02-12 20:18

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.

bap added a comment - 2012-02-12 20:18 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.

Ulli Hafner added a comment - 2012-02-14 12:44

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?

Ulli Hafner added a comment - 2012-02-14 12:44 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?

SCM/JIRA link daemon added a comment - 2012-02-14 21:08

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

SCM/JIRA link daemon added a comment - 2012-02-14 21:08 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

bap added a comment - 2012-02-14 21:32

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.

bap added a comment - 2012-02-14 21:32 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.

Ulli Hafner added a comment - 2012-02-15 09:30

Ok, thanks for fixing that!

Ulli Hafner added a comment - 2012-02-15 09:30 Ok, thanks for fixing that!

People

Assignee:: bap

Reporter:: Ulli Hafner

Votes:: 0 Vote for this issue

Watchers:: 0 Start watching this issue

Dates

Created:: 2012-02-09 14:12

Updated:: 2012-02-15 09:30

Resolved:: 2012-02-14 21:51