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

f:repeatable components displayed inconsistently in Builder plugin

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None

      When I first create a new job and add my Builder to the build steps, the f:repeatable appears empty (see no-elements.png). I save that configuration and Hudson produces this config.xml:

      <?xml version='1.0' encoding='UTF-8'?>
      <project>
      <actions/>
      <description></description>
      <keepDependencies>false</keepDependencies>
      <properties/>
      <scm class="hudson.scm.NullSCM"/>
      <canRoam>true</canRoam>
      <disabled>false</disabled>
      <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
      <triggers class="vector"/>
      <concurrentBuild>false</concurrentBuild>
      <builders>
      <com.example.HelloWorldBuilder/>
      </builders>
      <publishers/>
      <buildWrappers/>
      </project>

      When I reload the job/test/configure page the f:repeatable component all of the sudden contains one element (see one-element.png). This should not happen unless the config.xml looks something like:

      <?xml version='1.0' encoding='UTF-8'?>
      <project>
      <actions/>
      <description></description>
      <keepDependencies>false</keepDependencies>
      <properties/>
      <scm class="hudson.scm.NullSCM"/>
      <canRoam>true</canRoam>
      <disabled>false</disabled>
      <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
      <triggers class="vector"/>
      <concurrentBuild>false</concurrentBuild>
      <builders>
      <com.example.HelloWorldBuilder>
      <configurables>
      <com.example.HelloWorldBuilder_-Configurable>
      <selectedOption></selectedOption>
      </com.example.HelloWorldBuilder_-Configurable>
      </configurables>
      </com.example.HelloWorldBuilder>
      </builders>
      <publishers/>
      <buildWrappers/>
      </project>

      Sample plugin code can be found at: http://github.com/plouj/testHudsonSelect/tree/350ad201c209ba393d6a3d417b34a9ceac466ba1

      Steps to reproduce:
      1 - build and plugin
      cd testRecorder && mvnDebug hpi:run
      2 - create a new free-style project named "test"
      3 - add a "Test selection" build step
      on the initial job configuration page click "Add build step"
      select "Test selection"
      4 - notice that the "Configurables" section correctly contains nothing other than an "Add" button (see no-elements.png)
      5 - just save the job configuration
      6 - verify that the job config.xml file just says:
      ...
      <builders>
      <com.example.HelloWorldBuilder/>
      </builders>
      ...
      without any sub-elements
      7 - reload the job configuration page
      browse to job/test/configure
      8 - notice that now the "Configurables" section incorrectly contains a dropdown menu labeled "Select an option:" besides the "Add" button (see one-element.png). This represents an element which has not been read from the disk (config.xml).
      9 - for a sanity check save the job again
      10 - notice that config.xml now shows one "configurable" element as expected:
      ...
      <builders>
      <com.example.HelloWorldBuilder>
      <configurables>
      <com.example.HelloWorldBuilder_-Configurable>
      <selectedOption></selectedOption>
      </com.example.HelloWorldBuilder_-Configurable>
      </configurables>
      </com.example.HelloWorldBuilder>
      </builders>
      ...

          [JENKINS-6679] f:repeatable components displayed inconsistently in Builder plugin

          Alan Harder added a comment -

          I was able to reproduce the problem.. thanks for providing sample code and steps.

          The problem is when items="${instance.configurable}" evaluates to null, f:repeatable was inheriting ${items} from the outer jelly, ie the list of builders. I'm making f:repeatable use ${attrs.items} which means it only uses the items= attribute specifically on the <f:repeatable>.
          If you want a workaround for current Hudson versions, you can put
          <j:set var="items" value="${null}"/>
          just before your <f:repeatable>.
          Or you could make getConfigurables in your java class return an empty list when the configurables field is null..

          Alan Harder added a comment - I was able to reproduce the problem.. thanks for providing sample code and steps. The problem is when items="${instance.configurable}" evaluates to null, f:repeatable was inheriting ${items } from the outer jelly, ie the list of builders. I'm making f:repeatable use ${attrs.items } which means it only uses the items= attribute specifically on the <f:repeatable>. If you want a workaround for current Hudson versions, you can put <j:set var="items" value="${null}"/> just before your <f:repeatable>. Or you could make getConfigurables in your java class return an empty list when the configurables field is null..

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/core/src/main/resources/lib/form/repeatable.jelly
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/31634
          Log:
          [FIXED JENKINS-6679] use ${attrs.items} so f:repeatable will not inherit
          an outer list if the given items was null.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/resources/lib/form/repeatable.jelly trunk/www/changelog.html http://jenkins-ci.org/commit/31634 Log: [FIXED JENKINS-6679] use ${attrs.items} so f:repeatable will not inherit an outer list if the given items was null.

            mindless Alan Harder
            plouj plouj
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: