Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Minor
-
Resolution: Unresolved
-
Component/s: warnings-plugin
-
Labels:None
-
Environment:Jenkins ver. 2.138.3 (Docker Hub)
Wanings NG 1.0.0-beta5
-
Similar Issues:
Description
(discussion is split from JENKINS-54759)
Issue
console parsers currently run on the master and for security reasons, this excludes the customizable Groovy Parser.
for an user this is surprising and adding a custom warning parser will need changes in the buildscript to dump output to a log file, ideally adding a parser would not otherwise affect existing jobs .
- not piping would be the most clear, and similar to the scripts you would run on a local build
- piping it just to a file will remove all visible status during execution
- naively splitting it (eg. | tee file.log) will mean the error state of the script doing the build will vanish. see here
- additionally storing and restoring the errors state of the script adds boilerplate code
just to reiterate how invasive this change is, here is my current (POSIX Shell) workaround with variant 4):
before:
sh buildscript.sh ARGS...
after:
pipe_retval() {
local LOGFILE=$1; shift
(((("$@" 2>&1; echo $? >&3) | tee "$LOGFILE" >&4) 3>&1) | (read xs; exit $xs)) 4>&1
}
pipe_retval build.log sh buildscript.sh ARGS...
Attachments
Issue Links
- is duplicated by
-
-
- Resolved
-
Activity
Maybe this thread helps as well: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jenkinsci-users/Tkh8v07v_Cs/uvx3az-4BQAJ
I picked the above workaround, as this works with any POSIX shells, credit goes out to: unix.stackexchange.com.
the workaround with `set -o pipefail`only works with bash, and therefore does not work if you for ex. use alpine linux.
Norbert Lange
added a comment - I picked the above workaround, as this works with any POSIX shells, credit goes out to: unix.stackexchange.com .
the workaround with `set -o pipefail`only works with bash, and therefore does not work if you for ex. use alpine linux. If you don't know it yet, you should take a look at the tee step. This does what it should and automatically propagates the return codes of any failed steps inside of the tee.
Daniel Saier
added a comment - If you don't know it yet, you should take a look at the tee step . This does what it should and automatically propagates the return codes of any failed steps inside of the tee. Daniel Saier: No I did not knew about this yet, I proposed practically the same thing in JENKINS-44930. Thanks.
That seems to be the proper solution for me now, as I prefer feeding just the output from the build command to the warnings-plugin (vs. using the whole log output)
Norbert Lange
added a comment - Daniel Saier : No I did not knew about this yet, I proposed practically the same thing in JENKINS-44930 . Thanks.
That seems to be the proper solution for me now, as I prefer feeding just the output from the build command to the warnings-plugin (vs. using the whole log output) 
I have the same problem and currently have to use ugly workarounds.
As I understand it, this limitation was introduced for JENKINS-52237. I don't require that functionality and the administrator is the only one who creates Groovy parsers on my system. Would it be possible to lift this restriction again for parsers that are configured through the admin interface (and thus don't have security problems when they run on the master)?