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

Label display wrong when using operators in expression

    • Icon: New Feature New Feature
    • Resolution: Done
    • Icon: Major Major
    • core
    • None
    • Jenkins ver. 1.532.2 LTS

      Behaviour:

      1. go to job configuration
      2. enable "Restrict where this project can be run"
      3. enter expression with operator, e.g. "label1&&label2"
      4. go to slave that is configured to run label1 and label2
      5. klick on label1 (link next to "Labels:")
      6. URL $your_jenkins/label/label1/? will open
      7. Project using "label1&&label2" won't be displayed, only projects that use "label1" and nothing else will be displayed

      Workaround: enter $your_jenkins/label/label1&&label2/ as URL


      Expected behaviour:

      Klicking on a label (i.e. navigating to $your_jenkins/label/label1/?) should display all jobs that actually make use of this label regardless of using it alone or in combination with other labels (via an operator).

        1. LJPa_jdk7.png
          LJPa_jdk7.png
          174 kB
        2. LJPa_macos.png
          LJPa_macos.png
          143 kB
        3. LJPa_unassigned.png
          LJPa_unassigned.png
          83 kB
        4. LJPb_jdk7.png
          LJPb_jdk7.png
          181 kB
        5. LJPb_macos.png
          LJPb_macos.png
          128 kB

          [JENKINS-23333] Label display wrong when using operators in expression

          Great job guys, looks really nice! Thanks a lot so far.

          Quick question: will the plug in be compatible to the latest LTS version?

          Steffen Breitbach added a comment - Great job guys, looks really nice! Thanks a lot so far. Quick question: will the plug in be compatible to the latest LTS version?

          Daniel Beck added a comment -

          dominiquebrice: Could have sworn /label/foo (and /computer/foo) showed a different type of list. Sorry about that. So the current state is consistent with the label and computer pages and needs no changes. (It may be best to make the list less noisy in core, and I think Tom Fennelly is working on that.)

          Ideas for improvement:

          • In the list, make sure to also show exact matches (repeat the list shown on /label/foo – unclear whether that's included currently)
          • Sort sections alphabetically by label (except the current label atom, that may be better when always the first one)
          • For every label expression, list the nodes that can handle it, like on the label main page ("Nodes" section on /label/foo)
          • Add model-links to /label/foo in every section, so users to the composite label's page from there

          sbreitbach: I think it's safe to assume this works on 1.554.x, if necessary with with minimal changes – I don't remember any relevant API changes since then.

          Daniel Beck added a comment - dominiquebrice : Could have sworn /label/foo (and /computer/foo ) showed a different type of list. Sorry about that. So the current state is consistent with the label and computer pages and needs no changes. (It may be best to make the list less noisy in core, and I think Tom Fennelly is working on that.) Ideas for improvement: In the list, make sure to also show exact matches (repeat the list shown on /label/foo – unclear whether that's included currently) Sort sections alphabetically by label (except the current label atom, that may be better when always the first one) For every label expression, list the nodes that can handle it, like on the label main page ("Nodes" section on /label/foo ) Add model-links to /label/foo in every section, so users to the composite label's page from there sbreitbach : I think it's safe to assume this works on 1.554.x, if necessary with with minimal changes – I don't remember any relevant API changes since then.

          Second round of screenshots

          Dominique Brice added a comment - Second round of screenshots

          Daniel, all points taken into account, see new screenshots. I still need to test on a multi-nodes environment.
          You will see my attempt to build a condensed view. I'm not a UI expert so I'm planning on releasing the plugin like that. I count on other contributors' talent to make it look better if need be!

          Steffen, I used the default "plugin skeleton generator", which generates a dependency on jenkins 1.532.3. I'm not familiar enough yet with jenkins versioning but I suppose it means the plugin will work on subsequent jenkins version

          This version 1.532.3 could also explain why some cool features I see in the latest 1.580-SNAPSHOT do not work in the test environment of my plugin... Daniel, do you think I should change the dependency to 1.554.1 (or 1.554.3)? Thanks

          Dominique Brice added a comment - Daniel, all points taken into account, see new screenshots. I still need to test on a multi-nodes environment. You will see my attempt to build a condensed view. I'm not a UI expert so I'm planning on releasing the plugin like that. I count on other contributors' talent to make it look better if need be! Steffen, I used the default "plugin skeleton generator", which generates a dependency on jenkins 1.532.3. I'm not familiar enough yet with jenkins versioning but I suppose it means the plugin will work on subsequent jenkins version This version 1.532.3 could also explain why some cool features I see in the latest 1.580-SNAPSHOT do not work in the test environment of my plugin... Daniel, do you think I should change the dependency to 1.554.1 (or 1.554.3)? Thanks

          Daniel Beck added a comment -

          Daniel, all points taken into account, see new screenshots. I still need to test on a multi-nodes environment.
          You will see my attempt to build a condensed view. I'm not a UI expert so I'm planning on releasing the plugin like that. I count on other contributors' talent to make it look better if need be!

          Looks great.

          I'm not familiar enough yet with jenkins versioning but I suppose it means the plugin will work on subsequent jenkins version

          That's the idea, yes. There are very few exceptions to this rule.

          do not work in the test environment of my plugin... Daniel, do you think I should change the dependency

          Generally, if the plugin can do everything you want with somewhat older core dependency, that's the way to go. Obviously, if you want to use newer APIs or need behavior fixes (e.g. there were several versions where automated tests were broken on Windows), those are reasons to go with newer core versions.

          The downside of an older core dependency is that this is used for automated tests and hpi:run, so while testing the plugin, you're using an older version. (You could always switch to a newer core during development to see how the plugin looks and works then, but do testing and releases with the older dependency so it's available to more users.)

          There's a report on stats.jenkins-ci.org that shows how many installations have version X or higher (i.e. if something was added in X, how many installations have it). It may help you decide which version to depend on. With 1.532.1, released 9 months ago, currently ~75% of installations could use your plugin, which seems reasonable.

          http://stats.jenkins-ci.org/plugin-installation-trend/capabilities.json

          Daniel Beck added a comment - Daniel, all points taken into account, see new screenshots. I still need to test on a multi-nodes environment. You will see my attempt to build a condensed view. I'm not a UI expert so I'm planning on releasing the plugin like that. I count on other contributors' talent to make it look better if need be! Looks great. I'm not familiar enough yet with jenkins versioning but I suppose it means the plugin will work on subsequent jenkins version That's the idea, yes. There are very few exceptions to this rule. do not work in the test environment of my plugin... Daniel, do you think I should change the dependency Generally, if the plugin can do everything you want with somewhat older core dependency, that's the way to go. Obviously, if you want to use newer APIs or need behavior fixes (e.g. there were several versions where automated tests were broken on Windows), those are reasons to go with newer core versions. The downside of an older core dependency is that this is used for automated tests and hpi:run , so while testing the plugin, you're using an older version. (You could always switch to a newer core during development to see how the plugin looks and works then, but do testing and releases with the older dependency so it's available to more users.) There's a report on stats.jenkins-ci.org that shows how many installations have version X or higher (i.e. if something was added in X, how many installations have it). It may help you decide which version to depend on. With 1.532.1, released 9 months ago, currently ~75% of installations could use your plugin, which seems reasonable. http://stats.jenkins-ci.org/plugin-installation-trend/capabilities.json

          Dominique Brice added a comment - - edited

          Initial release 1.0.1 of the plugin published, already available in the repo:
          http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/label-linked-jobs/1.0.1/

          Should appear soon in Jenkins plugin management section.

          Edit: wiki page is done.

          Steffen, let us know how it goes for you!

          Dominique Brice added a comment - - edited Initial release 1.0.1 of the plugin published, already available in the repo: http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/label-linked-jobs/1.0.1/ Should appear soon in Jenkins plugin management section. Edit: wiki page is done. Steffen, let us know how it goes for you!

          Daniel Beck added a comment -

          I think this issue can be resolved, WDYT Steffen?


          dominiquebrice:

          new "Labels Dashboard" to have a global view of all labels defined and used in jobs & nodes

          Looks like I can finally kill off my own (mostly abandoned) attempts at writing better labels UI. I'm really looking forward to what you're going to add to the plugin next!

          Daniel Beck added a comment - I think this issue can be resolved, WDYT Steffen? dominiquebrice : new "Labels Dashboard" to have a global view of all labels defined and used in jobs & nodes Looks like I can finally kill off my own (mostly abandoned) attempts at writing better labels UI . I'm really looking forward to what you're going to add to the plugin next!

          Daniel, let's continue the discussion about the plugin on this page.
          Steffen, I can now see the plugin (v1.0.1) proposed in the plugin management section. Does the install worked well for you?

          Dominique Brice added a comment - Daniel, let's continue the discussion about the plugin on this page . Steffen, I can now see the plugin (v1.0.1) proposed in the plugin management section. Does the install worked well for you?

          I'm super busy at the moment. I managed to install it but didn't have the time yet to restart Jenkins and have a closer look. Sorry.

          I'll look at this as soon as possible.

          Steffen Breitbach added a comment - I'm super busy at the moment. I managed to install it but didn't have the time yet to restart Jenkins and have a closer look. Sorry. I'll look at this as soon as possible.

          I set it to "done" (via a plugin) rather than "fixed" (behavior in Jenkins core remains the same).

          Dominique Brice added a comment - I set it to "done" (via a plugin) rather than "fixed" (behavior in Jenkins core remains the same).

            Unassigned Unassigned
            sbreitbach Steffen Breitbach
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: