an example pipeline

      ...
      def myBuild = build ...
      ...
      

      `myBuild` ends up in as `org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper`.

      The way to get downstream build log would be by `myBuild.rawBuild...` but `rawBuild` is not whitelisted in the script security plugin. Also in the console where it can be allowed I see

      signature : method org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper getRawBuild Approving this signature may introduce a security vulnerability! You are advised to deny it.

      So my request is to allow somehow getting the downstream build log without security risks.

      Thank you!

          [JENKINS-46376] Allow getting log through RunWrapper

          akostadinov added a comment -

          If log is available similar to how current build log is available through the `manager.getLogMatcher` that should also do the job. The main thing is to have ability to inspect the log of the downstream build.

          akostadinov added a comment - If log is available similar to how current build log is available through the `manager.getLogMatcher` that should also do the job. The main thing is to have ability to inspect the log of the downstream build.

          Andrew Bayer added a comment -

          Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/workflow-support-plugin/pull/51 adding myBuild.log .

          Brian M added a comment -

          Any update on this?

          The last update was on "2018-01-12 14:02"

          Brian M added a comment - Any update on this? The last update was on "2018-01-12 14:02"

          really need a mechanism to safely access the build log inside declarative pipelines ... any ETA on this?

          Alan Czajkowski added a comment - really need a mechanism to safely access the build log inside declarative pipelines ... any ETA on this?

          Devin Nusbaum added a comment -

          I'm not sure about adding direct access to build logs from the Pipeline itself. We do not want to encourage users to process large amounts of data directly in their Pipelines, as that often leads to serious performance issues. It would be great to get some examples of what users are looking for in the downstream build logs (build results, errors, etc.). Maybe we could create/expose a different step for structured cross-build communications that could be used from Pipelines that would avoid the drawbacks of direct log access.

          Devin Nusbaum added a comment - I'm not sure about adding direct access to build logs from the Pipeline itself. We do not want to encourage users to process large amounts of data directly in their Pipelines, as that often leads to serious performance issues. It would be great to get some examples of what users are looking for in the downstream build logs (build results, errors, etc.). Maybe we could create/expose a different step for structured cross-build communications that could be used from Pipelines that would avoid the drawbacks of direct log access.

          Axel Heider added a comment -

          Our use case is that we create a build result package with the artifacts, which is then picked up by various tests. It's good to have the build log in this package, so in case the test are failing there is some insight if it might have been a build issues already. In the tests stages we have the same thing, having the jenkins test logs in the test result package provides more background information in case of failures.

          In general, having a log file in a job result package avoids a hard dependency on the jenkins server to see the logs. Given Jenkins can discard builds after a while, the log are log then. I can understand that that might be reasons not to make a log available to a build pipeline itself for security/trusts reasons. But a parent job that kicks of a build job should be able to get the log form this job, because it's implicitly trusted anyway. But it's stuck with the RunWrapper.

          Axel Heider added a comment - Our use case is that we create a build result package with the artifacts, which is then picked up by various tests. It's good to have the build log in this package, so in case the test are failing there is some insight if it might have been a build issues already. In the tests stages we have the same thing, having the jenkins test logs in the test result package provides more background information in case of failures. In general, having a log file in a job result package avoids a hard dependency on the jenkins server to see the logs. Given Jenkins can discard builds after a while, the log are log then. I can understand that that might be reasons not to make a log available to a build pipeline itself for security/trusts reasons. But a parent job that kicks of a build job should be able to get the log form this job, because it's implicitly trusted anyway. But it's stuck with the RunWrapper.

          Devin Nusbaum added a comment -

          The closest thing to this that exists today is the tee step from Pipeline Utility Steps plugin, which is a block-scope step that copies everything written to the build log from inside of that step to a file in the build's workspace. See here for an example of usage.

          Devin Nusbaum added a comment - The closest thing to this that exists today is the tee step from Pipeline Utility Steps plugin , which is a block-scope step that copies everything written to the build log from inside of that step to a file in the build's workspace. See here for an example of usage.

            Unassigned Unassigned
            akostadinov akostadinov
            Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: