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

Ambiguous actions in list of available actions

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • any-buildstep-plugin
    • None

      Over the past several months we had been dealing with what believed was a defect with several of our Jenkins plugins where by actions instantiated under a Flexible Publish post-build step were showing different options seemingly randomly (JENKINS-32275).

      It turns out that the root cause of our difficulties the entire time was our unawareness that when the any-build-step plugin is installed and enabled any plugins that support both build and post-build operations get listed twice in the available actions for the Flexible Publish and that both instances have the exact same action names making them indistinguishable.

      Here is an example use case of what I am talking about:

      1. setup a clean copy of Jenkins (we use v1.596.3)
      2. install the any-build-step plugin (v0.1) which should also install the Flexible Publish plugin (v0.15.2) among several others
      3. install a plugin that supports both build and post-build operations. With our ad-hoc tests at least the following plugins fall into this category:
        • description-setter-plugin (v1.10)
        • artifact-deployer (v0.33)
      4. next, open the Manage Jenkins -> Configure Settings admin panel and locate the section entitled "Flexible Publish"
      5. In the drop down list of "Allowed build steps" select "Any build step" and click Save
      6. now, create a new job / project of type "Freestyle Project"
      7. add a post-build action of type "Flexible Publish"
      8. Click the "Add" button to expose a drop-down list of available actions that can be added to the Flexible Publish. You will see two actions with the exact same name for each of the plugins listed in step 3, one of which refers to the "build" action variant and the other the "post-build" variant, each of which expose different configuration options.

      The main problem with this use case is that it is impossible to distinguish between the duplicate entries in the action list because they have the exact same name. In extreme cases like ours, if users don't realize there is duplication here they may incorrectly assume that sometimes the actions present different configuration options when created. To make matters worse the behavior appears random at first glance because it goes unnoticed that sometimes one may be selecting the "build" action while other times they may be selecting the "post-build" action.

      What I would suggest in cases like this is to extend the functionality of the any-buildstep-plugin such that when it compiles the list of available actions, if there are duplicate names in the list it take steps to figure out which one is associated with a "build" action and which is associated with a "post-build" action and have some kind of unique identifier prepended to the name of the action to help distinguish the two, something like this:

      • (build-step) Set build description
      • (post-build-step) Set build description

      Another alternative representation could perhaps provide two independent drop-down lists for actions, one containing just build actions and the other only post-build actions. Then each list would be explicit and mutually exclusive.

      Basically, I would consider this improvement resolved if there was any way to visually distinguish between identically named actions before adding them to the job configuration.

          [JENKINS-32550] Ambiguous actions in list of available actions

          Linked this improvement to the original defect that lead me to discover this very difficult to detect ambiguity. See the comment thread and screen shots attached to that defect for examples and details of the kinds of confusion this has caused us.

          Kevin Phillips added a comment - Linked this improvement to the original defect that lead me to discover this very difficult to detect ambiguity. See the comment thread and screen shots attached to that defect for examples and details of the kinds of confusion this has caused us.

          Attached a screen shot that illustrates the duplication I am looking to disambiguate here.

          Kevin Phillips added a comment - Attached a screen shot that illustrates the duplication I am looking to disambiguate here.

          NOTE: Given that the any-buildstep-plugin extends both the Flexible Publish and Conditional Build Step plugins, the same behavior is likely reproducible with the latter plugin as well, but I have not taken the time to confirm.

          Kevin Phillips added a comment - NOTE: Given that the any-buildstep-plugin extends both the Flexible Publish and Conditional Build Step plugins, the same behavior is likely reproducible with the latter plugin as well, but I have not taken the time to confirm.

            bap bap
            leedega Kevin Phillips
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: