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

The priorities defined in JCasC are not set correctly in Jenkins

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • prioritysorter-plugin
    • None
    • jenkins:2.414.3-lts-alpine
      priority-sorter 5.0.0

      Reproduction steps

      1. Set the following config for priority-sorter

      priorityConfiguration:
        jobGroups:
          - jobGroupStrategy: "allJobs"
            priority: -1
            priorityStrategies:
              - buildParameterStrategy:
                  parameterName: "PRIORITY"
              - userIdCauseStrategy:
                  priority: 4
            usePriorityStrategies: true
      prioritySorterConfiguration:
        onlyAdminsMayEditPriorityConfiguration: true
        strategy:
          absoluteStrategy:
            defaultPriority: 5
            numberOfPriorities: 7
      

      2. Start Jenkins with the above configuration

      Observed result

      The actual value of the userIdCausePriority is 3 as can be shown by extracting the configuration of the plugin from the instance of Jenkins.

      priorityStrategy:
        userIdCauseStrategy:
          priority: 3
      

      Expected result

      The expected value of the userIdCausePriority is 4 as defined in the input configuration file.

      priorityStrategy:
        userIdCauseStrategy:
          priority: 4
      

      Root cause

      The 'scale' method in PriorityCalculationsUtil seems to be called when the JCasC configuration is being applied. The method returns distorted results due to numerical anomalies - apparently the actual float values are a little smaller/bigger than expected ones (e.g. 0.3(9) instead of 0.4) so the used 'floor' and 'ceil' functions may lead to wrong results.

          [JENKINS-72401] The priorities defined in JCasC are not set correctly in Jenkins

          Jan added a comment -

          I suggest modifying the 'scale' method itself or changing the context in which it's called.

          Jan added a comment - I suggest modifying the 'scale' method itself or changing the context in which it's called.

          Mark Waite added a comment -

          Thanks for the report cytrek . There is an existing automated test that seems reasonably close to asserting the type of condition you're reporting. Are you interested in creating an automated test to show the problem and then proposing a change that fixes the automated test?

          Mark Waite added a comment - Thanks for the report cytrek . There is an existing automated test that seems reasonably close to asserting the type of condition you're reporting. Are you interested in creating an automated test to show the problem and then proposing a change that fixes the automated test?

          Jan added a comment -

          Sure, I'll work upon it.

          Jan added a comment - Sure, I'll work upon it.

          Jan added a comment - - edited

          I added a test covering the case from from the description but it passed so I removed it. Also I did some tests on my jenkins instance with the scale function exclusively and it works there fine as well. The problem must be somewhere else but I sadly can't investigate it. Also thank you markewaite for fixing my formatting - in logs there indeed was a message referring to that.

          Jan added a comment - - edited I added a test covering the case from from the description but it passed so I removed it. Also I did some tests on my jenkins instance with the scale function exclusively and it works there fine as well. The problem must be somewhere else but I sadly can't investigate it. Also thank you markewaite for fixing my formatting - in logs there indeed was a message referring to that.

            Unassigned Unassigned
            cytrek Jan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: