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

Being able to configure some parameters after choosing a parser

    XMLWordPrintable

Details

    • New Feature
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Fixed
    • warnings-plugin
    • None
    • jenkins : 1.504
      plug-in warning : 4.35
    • 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

          drulli Ulli Hafner added a comment - See documentation .
          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).

          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).
          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 ?

          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 ?
          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.

          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.
          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

           

          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  
          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.

          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.

          People

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

            Dates

              Created:
              Updated:
              Resolved: