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

being able to configure a new parser with groovy script directly from the job configuration

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • warnings-ng-plugin
    • None
    • jenkins : 1.504
      plug-in warning : 4.35

      we have several users and one admin.

      admin guy (myself) create some parser.

      it would be great if it could be possible for a user to choose a parser and being able to modify it (locally for its job). or even create a new one.

      because it is annoying to provide administrative right to users only for the parser creation.

          [JENKINS-52237] being able to configure a new parser with groovy script directly from the job configuration

          Ulli Hafner added a comment -

          It is in the admin section due to security reasons: the script can basically do anything on your system so it is only safe to be checked by an admin.

          I think we found a secure workaround for this: I will prohibit Groovy parsers to scan the console log. They are permitted only to scan files on the agent. Then only an agent might be compromised by a not well behaving script.

          Ulli Hafner added a comment - It is in the admin section due to security reasons: the script can basically do anything on your system so it is only safe to be checked by an admin. I think we found a secure workaround for this: I will prohibit Groovy parsers to scan the console log. They are permitted only to scan files on the agent. Then only an agent might be compromised by a not well behaving script.

          Nick Jones added a comment -

          The older Warnings plugin is the only way to define a custom console parser given this restriction – so this is a regression in functionality, blocking us from fully moving over to Warnings NG. Since the system-level parsers are able to be defined only by Jenkins administrators, how about allowing those parsers to access the console log while allowing job-level custom parsers to access only files in the workspace?

          Nick Jones added a comment - The older Warnings plugin is the only way to define a custom console parser given this restriction – so this is a regression in functionality, blocking us from fully moving over to Warnings NG. Since the system-level parsers are able to be defined only by Jenkins administrators, how about allowing those parsers to access the console log while allowing job-level custom parsers to access only files in the workspace?

          Ernst de Haan added a comment -

          It would be nice if the parser would be configurable in a declarative manner. Then the security concerns would be alleviated and any job can just provide the configuration in a file.

          Ernst de Haan added a comment - It would be nice if the parser would be configurable in a declarative manner. Then the security concerns would be alleviated and any job can just provide the configuration in a file.

          Christopher Fenner added a comment - - edited

          We need to parse the whole job log, so using tee is not an option for us. This is really blocking us from moving forward to warnings-ng plugin. This I can do now by fetching the log from the currentBuild and writing it to a file.

          Christopher Fenner added a comment - - edited We need to parse the whole job log, so using tee is not an option for us. This is really blocking us from moving forward to warnings-ng plugin. This I can do now by fetching the log from the currentBuild and writing it to a file.

          For the old warnings plugin I could add a parser with 

          Jenkins.instance.getExtensionList(hudson.plugins.warnings.WarningsDescriptor.class).get(0).addGroovyParser(new hudson.plugins.warnings.GroovyParser(...))

          How can this be done for the new warnings-ng plugin?

           

          Christopher Fenner added a comment - For the old warnings plugin I could add a parser with  Jenkins.instance.getExtensionList(hudson.plugins.warnings.WarningsDescriptor.class).get(0).addGroovyParser( new hudson.plugins.warnings.GroovyParser(...)) How can this be done for the new warnings-ng plugin?  

          Ulli Hafner added a comment -

          This is not possible. Can't you add parsers using JCasC?

          Ulli Hafner added a comment - This is not possible. Can't you add parsers using JCasC?

          CaaC was a good hint, I now use this to add a parser on the fly:

          def config = io.jenkins.plugins.analysis.warnings.groovy.ParserConfiguration.getInstance()
          config.setParsers(
            config.getParsers().plus(
              new io.jenkins.plugins.analysis.warnings.groovy.GroovyParser(id, name, regex, script, example)
            )
          )
          

          Christopher Fenner added a comment - CaaC was a good hint, I now use this to add a parser on the fly: def config = io.jenkins.plugins.analysis.warnings.groovy.ParserConfiguration.getInstance() config.setParsers( config.getParsers().plus( new io.jenkins.plugins.analysis.warnings.groovy.GroovyParser(id, name, regex, script, example) ) )

          Ulli Hafner added a comment -

          Good to see. Where or how do you execute that script? Are you interested in adding a small section for this approach in the documentation?

          Ulli Hafner added a comment - Good to see. Where or how do you execute that script? Are you interested in adding a small section for this approach in the documentation ?

          We use this to position warnings/errors produced by pipeline shared library steps in pipeline runs more prominent on the job run by parsing with a custom message pattern.

          Sure, I'll have a look a the respective docs page.

          Christopher Fenner added a comment - We use this to position warnings/errors produced by pipeline shared library steps in pipeline runs more prominent on the job run by parsing with a custom message pattern. Sure, I'll have a look a the respective docs page.

            drulli Ulli Hafner
            iostrym iostrym
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: