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

Symbols for constants variables in workflow-cps

    Details

    • Similar Issues:

      Description

      I want to use enum names for parameters of steps in pipeline jobs like:

      def runWrapper = selectRun job: 'upstream-project-name', 
        selector: status(Successful) 
      

      Successful is an enum value.
      I believe workflow-cps can determine what Successful means as the type of status is required to be an enum type.

      Background:
      Run selector plugin is working to introduce {{@Symbol}}s: https://github.com/jenkinsci/run-selector-plugin/pull/14
      It allows scripts use run-selector like this:

      def runWrapper = selectRun job: 'upstream-project-name', 
        selector: status('Successful') 
      

      'Successful' will be resolved to BuildStatus.Successful with Enum.valueOf (BuildStatus is an enum type).

      But other selectors in run-selector often expects strings starting with lower-case letters. For example, PermalinkRunSelector expects "lastSuccessful". This causes inconsistencies of usages of selectors and should be confusing for users.
      On the other hands, allowing "successlful" for parameters of status means to define enum values with lower-case letters like BuildStatus.successlful. It is strange as Java code.

      I think this can be resolved by either of following ways:
      A. Allow to use enum names as properties:

      def runWrapper = selectRun job: 'upstream-project-name', 
        selector: status(Successful) 
      
      • Successful will be resolved to BuildStatus.Successful as it's specified as a parameter requiring BuildStatus type, just like status is resolved to StatusRunSelector as it's specified as a parameter requiring RunSelector type.

      B. Allow developers define aliases for enum values like:

      enum BuildStatus {
        @EnumSymbol("successful")
        Successful,
      }
      

      And I believe it makes sense to apply this not only to enum types, but also to enum-like types like hudson.model.Result.

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          Would it not be easier to just use the String constant, which is already supported by structs?

          Show
          jglick Jesse Glick added a comment - Would it not be easier to just use the String constant, which is already supported by structs ?
          Hide
          ikedam ikedam added a comment -

          > Would it not be easier to just use the String constant, which is already supported by structs?

          I don't know that feature (and I couldn't get what feature of structs-plugin you mean).
          Would you show me some examples?

          Show
          ikedam ikedam added a comment - > Would it not be easier to just use the String constant, which is already supported by structs? I don't know that feature (and I couldn't get what feature of structs-plugin you mean). Would you show me some examples?
          Hide
          jglick Jesse Glick added a comment -

          Well you can just pass the Enum.name() as a String. If for compatibility reasons it is impossible to rename the enum constant to something friendly to the script, we could just make structs accept Enum.toString() as a variant. That seems the simplest change by far.

          Show
          jglick Jesse Glick added a comment - Well you can just pass the Enum.name() as a String . If for compatibility reasons it is impossible to rename the enum constant to something friendly to the script, we could just make structs accept Enum.toString() as a variant. That seems the simplest change by far.
          Hide
          jglick Jesse Glick added a comment -

          IOW, make DescribableModel.coerce check toString after Enum.valueOf. Then you could write either

          status('Successful')
          

          or

          status('successful')
          

          There would be no need to define new annotations, patch workflow-cps, etc.

          Show
          jglick Jesse Glick added a comment - IOW, make DescribableModel.coerce check toString after Enum.valueOf . Then you could write either status( 'Successful' ) or status( 'successful' ) There would be no need to define new annotations, patch workflow-cps , etc.
          Hide
          ikedam ikedam added a comment -

          I got your point.
          It should be easier to extend the way translating string values rather than translating symbols.
          Though I still believe an annotation is the best way to define aliases, I'll abondon current requests and try to reimplement that new approach. Thanks!

          Show
          ikedam ikedam added a comment - I got your point. It should be easier to extend the way translating string values rather than translating symbols. Though I still believe an annotation is the best way to define aliases, I'll abondon current requests and try to reimplement that new approach. Thanks!

            People

            • Assignee:
              ikedam ikedam
              Reporter:
              ikedam ikedam
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: