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

Flexible publish plugin doesn't always instantiate correct child plugin

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Labels:
      None
    • Environment:
      Windows, Jenkins LTS 1.596.3. Flexible Publish 0.15.2
    • Similar Issues:

      Description

      I have discovered that some plugins provide inconsistent behavior with the flexible publish plugin and have isolated a specific use case that may be helpful for debugging and discussion.

      (Keep in mind that I have very little knowledge of the internal workings of Jenkins, so take some of my technical assumptions below within that context)

      Problem
      Using the flexible publish plugin to conditionally set the "Description" of a build using the Description Setter plugin seems to work correctly so long as you provide a single conditional operation to the flexible publish plugin, but when more conditional actions are added subsequent instances of the description setter plugin do not expose all of their available options on the Jenkins UI. In this example case, the first instance exposes an "Advanced..." button allowing the customization of extra parameters not presented in the default list of options, where as subsequent instances do not provide such a button. See the attached sample.png for a visual.

      Closer examination of the XML generated by the Jenkins UI reveals that the Flexible Publish plugin is making reference to two different Jenkins plugins / classes for these divergent instances. In this example, the first instance of the Description Setter action is using a "DescriptionSetterPublisher" object, where as all subsequent instances are using a "DescriptionSetterBuilder" object, which may help shed some light on the problem. Below is a snippet from the config.xml for the job configuration presented in the attached screenshot:

      <org.jenkins__ci.plugins.flexible__publish.FlexiblePublisher plugin="flexible-publish@0.15.2">
          <publishers>
              <org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher>
                  <condition class="org.jenkins_ci.plugins.run_condition.logic.Not" plugin="run-condition@1.0">
                      <condition class="org.jenkins_ci.plugins.run_condition.core.BooleanCondition">
                          <token>${IS_CLEAN_BUILD}</token>
                      </condition>
                  </condition>
                  <publisherList>
                      <hudson.plugins.descriptionsetter.DescriptionSetterPublisher plugin="description-setter@1.10">
                          <regexp/>
                          <regexpForFailed/>
                          <description>OracleVersion: ${OracleVersion}</description>
                          <descriptionForFailed>OracleVersion: ${OracleVersion} </descriptionForFailed>
                          <setForMatrix>false</setForMatrix>
                      </hudson.plugins.descriptionsetter.DescriptionSetterPublisher>
                  </publisherList>
                  <runner class="org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail" plugin="run-condition@1.0"/>
                  <executionStrategy class="org.jenkins_ci.plugins.flexible_publish.strategy.FailAtEndExecutionStrategy"/>
              </org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher>
              
              <org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher>
                  <condition class="org.jenkins_ci.plugins.run_condition.core.BooleanCondition" plugin="run-condition@1.0">
                      <token>${IS_CLEAN_BUILD}</token>
                  </condition>
                  <publisherList>
                      <hudson.plugins.descriptionsetter.DescriptionSetterBuilder plugin="description-setter@1.10">
                          <regexp/>
                          <description>OracleVersion: both</description>
                      </hudson.plugins.descriptionsetter.DescriptionSetterBuilder>
                  </publisherList>
                  <runner class="org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail" plugin="run-condition@1.0"/>
                  <executionStrategy class="org.jenkins_ci.plugins.flexible_publish.strategy.FailAtEndExecutionStrategy"/>
              </org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher>
          </publishers>
      </org.jenkins__ci.plugins.flexible__publish.FlexiblePublisher>
      

      Based on this information, it appears as though somehow the Flexible Publisher correctly instantiates the first child object - since the options that are presented on the UI do appear to be complete and correct in this case - but subsequent instances are not correctly instantiated for some reason.

      I am assuming here that the underlying problem is some inherent implementation problem in the Flexible Publish plugin, however I suppose it could be a problem with the Description Setter plugin as well. I probably should mention that I have found similar behavior with other Jenkins plugins when used under the Flexible Publisher which does seem to reinforce my assumption. Also, given the fact the first instance of a child plugin under Flexible Publish does get instantiated correctly it suggests that the interaction between the two does work correctly in some cases which again seems to reinforce my assumption since if the link between the publisher and the child plugins were broken I would expect them to never work which is clearly not the case.

        Attachments

          Issue Links

            Activity

            Hide
            leedega Kevin Phillips added a comment -

            FYI: For kicks I took a quick look through our production system to see if there were duplication references to the Artifact Deployer actions as well, and there are! This would seem to suggest that at least part of the problem we have been experiencing is a result of duplicate entries with the exact same names showing up in the list of available actions, but only under certain specific conditions / circumstances.

            Show
            leedega Kevin Phillips added a comment - FYI: For kicks I took a quick look through our production system to see if there were duplication references to the Artifact Deployer actions as well, and there are! This would seem to suggest that at least part of the problem we have been experiencing is a result of duplicate entries with the exact same names showing up in the list of available actions, but only under certain specific conditions / circumstances.
            Hide
            ikedam ikedam added a comment -
            • There are two "set build description".
            • Different configuration sections for those two "set build description". (of build step and of post build step)

            Those above behaviors are expected and consistent ones.

            The problem you point is

            • You can't add more than two "set build description" of post build step.

            Right?

            I can't reproduce the problem in my environment.
            I attached a screen shot showing that I could add more than two "set build description" of post build step.

            I can't get what you want to explain with post_build_actions.png.
            Any-build-step only affects the behavior of flexible-publish (and conditional-buildstep) and never affects "Add post-build action" of projects.
            Attach a screenshot of the list of "Add" of flexible-publish actions for the second "set build description".

            Show
            ikedam ikedam added a comment - There are two "set build description". Different configuration sections for those two "set build description". (of build step and of post build step) Those above behaviors are expected and consistent ones. The problem you point is You can't add more than two "set build description" of post build step. Right? I can't reproduce the problem in my environment. I attached a screen shot showing that I could add more than two "set build description" of post build step. I can't get what you want to explain with post_build_actions.png. Any-build-step only affects the behavior of flexible-publish (and conditional-buildstep) and never affects "Add post-build action" of projects. Attach a screenshot of the list of "Add" of flexible-publish actions for the second "set build description".
            Hide
            leedega Kevin Phillips added a comment - - edited

            The problem you point is

            • You can't add more than two "set build description" of post build step.

            Right?

            Actually no. The original problem was that sometimes adding one of these actions as a post-build step resulted in the "Advanced" button being enabled while other times it was not.

            I can't get what you want to explain with post_build_actions.png.
            Any-build-step only affects the behavior of flexible-publish (and conditional-buildstep) and never affects "Add post-build action" of projects.

            I think therein lies some of my confusion. I thought the any-build-step plugin worked on arbitrary build / post-build steps. I hadn't realized that it only applies to flexible-publish and conditional-buildstep. I will limit subsequent testing to just those to areas.

            Also, given this fact I think the second point for confusion that I hadn't realized until yesterday was that in this case plugins such as set-build-description show up twice in the list of available actions - one representing a build step and one representing a post-build step - each of which present different options in the UI. I suspect that part of my problem in reporting this bug is that during testing I would occasionally click the former while other times I'd click the latter without realizing it.

            At least one improvement that could be made to the UI to avoid confusion would be to append / prepend some kind of indicator to distinguish duplicate action names like this. Maybe the any-build-step plugin could be enhanced such that if it detects two actions with the same name it could put a "(build)" or "(post-build)" label in front of the action name to avoid the ambiguity.

            That being said, when I was ad-hoc testing yesterday in my clean Jenkins environment I could have sworn that I managed to reproduce the behavior of the actions being created as build and post-build versions at random. I will do a bit more ad-hoc testing this morning to try and find a reproducible use case. If I can not find one I think it would be safe to say that this defect was actually attributed to human error caused by ambiguous duplication of action names, in which case enhancing the any-build-step plugin like what I suggested above could be a reasonable solution to this problem.

            Show
            leedega Kevin Phillips added a comment - - edited The problem you point is You can't add more than two "set build description" of post build step. Right? Actually no. The original problem was that sometimes adding one of these actions as a post-build step resulted in the "Advanced" button being enabled while other times it was not. I can't get what you want to explain with post_build_actions.png. Any-build-step only affects the behavior of flexible-publish (and conditional-buildstep) and never affects "Add post-build action" of projects. I think therein lies some of my confusion. I thought the any-build-step plugin worked on arbitrary build / post-build steps. I hadn't realized that it only applies to flexible-publish and conditional-buildstep. I will limit subsequent testing to just those to areas. Also, given this fact I think the second point for confusion that I hadn't realized until yesterday was that in this case plugins such as set-build-description show up twice in the list of available actions - one representing a build step and one representing a post-build step - each of which present different options in the UI. I suspect that part of my problem in reporting this bug is that during testing I would occasionally click the former while other times I'd click the latter without realizing it. At least one improvement that could be made to the UI to avoid confusion would be to append / prepend some kind of indicator to distinguish duplicate action names like this. Maybe the any-build-step plugin could be enhanced such that if it detects two actions with the same name it could put a "(build)" or "(post-build)" label in front of the action name to avoid the ambiguity. That being said, when I was ad-hoc testing yesterday in my clean Jenkins environment I could have sworn that I managed to reproduce the behavior of the actions being created as build and post-build versions at random. I will do a bit more ad-hoc testing this morning to try and find a reproducible use case. If I can not find one I think it would be safe to say that this defect was actually attributed to human error caused by ambiguous duplication of action names, in which case enhancing the any-build-step plugin like what I suggested above could be a reasonable solution to this problem.
            Hide
            leedega Kevin Phillips added a comment -

            All attempts to reproduce the "random" behavior I had originally experienced when reporting this defect have failed. I suspect the problem the entire time is that sometimes our users would be selecting the first action name from the list of actions while other times they were selecting the second instance. Since the action names are identical there was no easy / obvious way to tell them apart. In our case we have a large number of plugins installed so the duplicate action names were separated from one another by dozens of other actions so the duplication was not easily noticed making the behavior "seem" random.

            I would be content having this defect resolved and I have created a separate improvement request to find some way to disambiguate duplicate entries in the actions list when using the any-buildstep-plugin. See JENKINS-32550 for details.

            Thanks ikedam for your prompt replies and assistance with debugging this problem with me. It is greatly appreciated.

            Show
            leedega Kevin Phillips added a comment - All attempts to reproduce the "random" behavior I had originally experienced when reporting this defect have failed. I suspect the problem the entire time is that sometimes our users would be selecting the first action name from the list of actions while other times they were selecting the second instance. Since the action names are identical there was no easy / obvious way to tell them apart. In our case we have a large number of plugins installed so the duplicate action names were separated from one another by dozens of other actions so the duplication was not easily noticed making the behavior "seem" random. I would be content having this defect resolved and I have created a separate improvement request to find some way to disambiguate duplicate entries in the actions list when using the any-buildstep-plugin. See JENKINS-32550 for details. Thanks ikedam for your prompt replies and assistance with debugging this problem with me. It is greatly appreciated.
            Hide
            ikedam ikedam added a comment -

            I found that the issue was caused for you are confused with the same label "Set build description for a build step and a post build step.

            I close this issue with "Not a defect".

            You can create a new ticket for any-build-step plugin and request an improvement.
            This ticket is filled with confused descriptions and I don't think it's good idea to reuse this ticket.

            Show
            ikedam ikedam added a comment - I found that the issue was caused for you are confused with the same label "Set build description for a build step and a post build step. I close this issue with "Not a defect". You can create a new ticket for any-build-step plugin and request an improvement. This ticket is filled with confused descriptions and I don't think it's good idea to reuse this ticket.

              People

              • Assignee:
                ikedam ikedam
                Reporter:
                leedega Kevin Phillips
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: