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

Being able to configure some parameters after choosing a parser

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: warnings-plugin
    • Labels:
      None
    • Environment:
      jenkins : 1.504
      plug-in warning : 4.35
    • Similar Issues:
    • Released As:
      5.0.0-beta3

      Description

      2 possibilites :

      being able when creating a job to choose a parser for this plugin + also choose a value for one or two or 3 parameters.

      The number and name of parameters could be configured in the parser configuration in jenkins configuration.

      Then these parameters could be used in the groovy script.

      Exemple of use :

      parser toto choosen with parameter "severity = error only"

      then in the groovy script we could ignore all warning that don't have the severity error.

       

      currently each time a project need a little modification of a parser, I need to create a new parsed that is quite identical to the first one. When a bug is detected I need to correct several parser.

       

      only one parser with configuration is cost and time effective

        Attachments

          Activity

          Hide
          drulli Ulli Hafner added a comment -

          It might make sense that you implement your parsers in Java using a custom plugin. Then you can using sub-classing to solve that problem.

          Show
          drulli Ulli Hafner added a comment - It might make sense that you implement your parsers in Java using a custom plugin. Then you can using sub-classing to solve that problem.
          Hide
          iostrym iostrym added a comment -

          thanks for your answer, it would be a shame as your plugin is very handfull to use. I don't think I would be able to create my own parser plugin from scratch. And I thought my proposal would be a tiny upgrade. When one parser is selected, then a second list is available to provided parameters configured if they are.

          it would very pratical to be able to have very little variation around one parser. Because as I described, when lot of parsers are configured, it become painful to maintain when you need to correct one, all other variation need to be corrected also

           

          About the parser number problematic also, could it be possible for a user to have "information" about the parser used like a short sentence that would be configured but admin during the parser creation ?

          For instance : 

          parser toto => this parser is used for parsing tool XXX messages

          parser titi => this parser is used for...

          But this is another subject

           

          Show
          iostrym iostrym added a comment - thanks for your answer, it would be a shame as your plugin is very handfull to use. I don't think I would be able to create my own parser plugin from scratch. And I thought my proposal would be a tiny upgrade. When one parser is selected, then a second list is available to provided parameters configured if they are. it would very pratical to be able to have very little variation around one parser. Because as I described, when lot of parsers are configured, it become painful to maintain when you need to correct one, all other variation need to be corrected also   About the parser number problematic also, could it be possible for a user to have "information" about the parser used like a short sentence that would be configured but admin during the parser creation ? For instance :  parser toto => this parser is used for parsing tool XXX messages parser titi => this parser is used for... But this is another subject  
          Hide
          drulli Ulli Hafner added a comment - - edited

          My plug-in is designed to be extended by small custom parsers. These parsers are as small as the groovy ones, here an example.

          You can even add a description for each parser if you implement them natively.

          Show
          drulli Ulli Hafner added a comment - - edited My plug-in is designed to be extended by small custom parsers. These parsers are as small as the groovy ones, here an example . You can even add a description for each parser if you implement them natively.
          Hide
          iostrym iostrym added a comment -

          thanks a lot. so instead of using groovy script parser, we can write small java parser.

          where must be stored this new java file ?

          if there is a parameter in this script, how can the parameter value be configured by the user job ?

          Show
          iostrym iostrym added a comment - thanks a lot. so instead of using groovy script parser, we can write small java parser. where must be stored this new java file ? if there is a parameter in this script, how can the parameter value be configured by the user job ?
          Hide
          drulli Ulli Hafner added a comment - - edited

          The Java files need to be placed into a new plug-in.

          Parameters are only supported in the next major release. Example of the planned feature:

          You can then set the parameter during job configuration (UI or pipeline script).

          Show
          drulli Ulli Hafner added a comment - - edited The Java files need to be placed into a new plug-in. Parameters are only supported in the next major release. Example of the planned feature: FindBugs parser with parameter Configuration of the FindBugs parser You can then set the parameter during job configuration (UI or pipeline script).
          Hide
          drulli Ulli Hafner added a comment -
          Show
          drulli Ulli Hafner added a comment - See documentation .

            People

            Assignee:
            drulli Ulli Hafner
            Reporter:
            iostrym iostrym
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: