Add getLog() to whitelist #27
Conversation
| @@ -162,6 +162,11 @@ public String getFullProjectName() throws AbortException { | |||
| } | |||
|
|
|||
| @Whitelisted | |||
| public List<String> getLog(int maxLines) throws IOException { | |||
| return build().getLog(maxLines); | |||
There was a problem hiding this comment.
Possibly bad for performance if the argument is large. On the other hand sometimes you would want the full log. jenkinsci/workflow-basic-steps-plugin#2 might provide a more scalable solution, at least for the common case of scanning for messages in the current build’s log after an error (this method could be used for other purposes, such as after a build step).
| @@ -3,6 +3,7 @@ | |||
| <dt><code>result</code></dt><dd>typically <code>SUCCESS</code>, <code>UNSTABLE</code>, or <code>FAILURE</code> (<em>may</em> be null for an ongoing build)</dd> | |||
| <dt><code>displayName</code></dt><dd>normally <code>#123</code> but sometimes set to, e.g., an SCM commit identifier</dd> | |||
| <dt><code>description</code></dt><dd>additional information about the build</dd> | |||
| <dt><code>log</code></dt><dd>console output of the build</dd> | |||
There was a problem hiding this comment.
This is a method, not a property, so must be documented differently.
|
cf. #51 |
|
I am going to go ahead and close this. I think we should discuss this further on JENKINS-46376 to make sure we understand the use cases, and so that we can try to find an approach that doesn't encourage users to process logs directly in their Pipelines. |
It would be nice to get build logs without approving
method org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper getRawBuild, which is fairly permissive.