CpsFlowExecution: parseScript(): log "Method Too Large" situations more readably #817
Conversation
|
Out of curiosity, what output does this give you and how is it helpful? |
plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java
Outdated
Show resolved
Hide resolved
plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java
Outdated
Show resolved
Hide resolved
…to avoid catching by full name Signed-off-by: Jim Klimov <[email protected]>
…argeExceptionRealistic() tests Signed-off-by: Jim Klimov <[email protected]>
…sException as a carrier of MethodTooLargeException; re-throw with just a compact message to appear in the build log Signed-off-by: Jim Klimov <[email protected]>
|
Tests helped me realize that the PR updated with handling of both eventualities, and if the only exception in view is the MTL - re-throw with a short message avoiding a wall of text in pipeline log. From self-test console (showing both server log Still got a bit of stack trace from generic handling, but it is reasonably short - the ultimate pipeline devs won't have to scroll up a couple of screenfuls just to learn that their script was too long or complex. Now that the message is visible to end users, I am open to suggestions how to make it more actionable, and/or if the e.g. to explain about script length or its coding complexity and what to do about it (nesting, amount of stages, separation of methods into JSL classes, etc.); maybe point to a knowledge-base URL for a better maintainable article on the subject (don't want to replace one wall of text in the logs with another, right?) |
plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java
Outdated
Show resolved
Hide resolved
plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java
Outdated
Show resolved
Hide resolved
…unt to satisfy different CI platforms Signed-off-by: Jim Klimov <[email protected]>
…t importing the class Signed-off-by: Jim Klimov <[email protected]>
…uggestions for pipeline devs Signed-off-by: Jim Klimov <[email protected]>
… expected matching line Signed-off-by: Jim Klimov <[email protected]>
Until today, it was helpful to myself and a few colleagues who may/can/do follow traces of the Jenkins server logs when developing pipelines (testing in private Jenkins instances and those wrapped by IDEs notwithstanding). After the review comments some months ago (thanks, and sorry for not noticing) and a coding effort today, this should be better visible and more "actionable" to a more general population - now shown as a smaller wall of text right in the pipeline build logs: ...which is IMHO a bit more comprehensible than the original (especially the first time you see it): ...and requires less scrolling to get to the crux of the issue =D |
…ethods (class complexity) from maxTryCatch (nesting depth) Signed-off-by: Jim Klimov <[email protected]>
There was a problem hiding this comment.
The logic here is pretty convoluted and seems excessive when we do not really need to make things particularly pretty, we just need to offer some clue beyond what there is today. Would suffice to do something along the lines of
if (Functions.printThrowable(x).containsString("MethodTooLargeException")) {
throw new IllegalArgumentException("…your hint here…", x);
} else {
throw x;
}| } catch (RuntimeException | Error x) { | ||
| } catch (Exception x) { |
There was a problem hiding this comment.
This loses handling of Error, especially LinkageError.
There was a problem hiding this comment.
I think I had some troubles compiling catch (Exception | Error x), or just IDE warnings, can try.
There was a problem hiding this comment.
I see, it was an IDEA misconfiguration that had too old a "Language level" (claimed "5") set to support multi-catches.
FWIW, IDEA-generated update to the recipe (not committed here) is:
diff --git a/plugin/pom.xml b/plugin/pom.xml
index 71404738..1d44a5bb 100644
--- a/plugin/pom.xml
+++ b/plugin/pom.xml
@@ -286,6 +286,14 @@
<compatibleSinceVersion>2.18</compatibleSinceVersion>
</configuration>
</plugin>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-compiler-plugin</artifactId>
+ <configuration>
+ <source>7</source>
+ <target>7</target>
+ </configuration>
+ </plugin>
</plugins>
</build>
</project>
(1/1) Stage this hunk [y,n,q,a,d,e,p,?]? n
There was a problem hiding this comment.
Code updated to restore these Throwable descendant types.
plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java
Outdated
Show resolved
Hide resolved
…wExecution.java Do not log to server console log (not all server admins are those who run the projects with issues). Co-authored-by: Jesse Glick <[email protected]>
| if (ecCount > 1) { | ||
| // Not squashing with explicit MethodTooLargeException | ||
| // re-thrown below, in this codepath we have other errors. | ||
| throw new RuntimeException(msg, x); | ||
| } else { | ||
| // Do not confuse pipeline devs by a wall of text in the | ||
| // build console, but let the full context be found in | ||
| // server log with some dedication. | ||
| LOGGER.log(Level.FINE, mtlEx.getMessage()); | ||
| //throw new RuntimeException(msg, mtlEx); | ||
| throw new RuntimeException(msg); | ||
| } |
There was a problem hiding this comment.
Regarding the concern of "pretty convoluted logic" - this block is largely why I did it so: groovy can return a MultipleCompilationErrorsException with an attached collection of one or more errors (broadly speaking), so we need to count if we only had the MethodTooLargeException one way or another here (and then print the pretty log), or also something else and then better print everything for human devs to sift through it diligently.
plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java
Outdated
Show resolved
Hide resolved
|
Sorry it took a while to notice that there was finally a new review here - too many browser tabs open to keep track of such :D Thanks for doing it! |
|
Hm, got another use-case to handle: managed to get a step definition too large (aka "global variable", anyhow in JSL as So the pipeline chugged along until it called that step - and that's where the job crashed, with a different exception: Note there are actually two lines Gotta look into the structure of |
Notably, the latter is a Throwable but not an Exception so e.g. LinkageError might be not handled. Signed-off-by: Jim Klimov <[email protected]>
|
Posted the updated code to recognize the newly seen exception from Method Too Large in a JSL. I'll be testing a build with this on servers I manage, to get some first-hand feedback. A few things of note are:
|
…lass) for MethodTooLargeException handling And re-word logging (impacted class name, possible excerpts from trace). Not only WorkflowScript (pipeline) suffers from this, see examples in jenkinsci#817 Signed-off-by: Jim Klimov <[email protected]>
|
Heh, the code path which leads to MTL stack trace for steps/classes from JSL apparently lands into a different method's try/catch. Reworking the plugin change for the not- |
…ging of pretty-printing certain error handling Signed-off-by: Jim Klimov <[email protected]>
Signed-off-by: Jim Klimov <[email protected]>
|
Figured it out locally, preparing refactored PR contents as a meaningful series of commits :) |
…c from parseScript() into a method of its own I first wanted it to just throw the exceptions, but IDEA was upset that we might return from the catch block and then use the uninitialized "s" variable. So this new method returns the entity which we clearly throw from the catch block. Signed-off-by: Jim Klimov <[email protected]>
…ectedMethodTooLarge()" as too generic Curiously, before this PR jenkinsci#817 it had no qualms to "throw x" which could be a RuntimeException or Error, and the method itself only declares that it "throws IOException" which is neither. Even now explicitly-cast rethrows seem acceptable :\ Signed-off-by: Jim Klimov <[email protected]>
…hodTooLarge(x)
Some loaded properties are in fact calls to resolve code from a
Jenkins Shared Library (steps aka global variables, or directly
class methods if using script{} blocks and not just declarative).
First accesses to such code cause CPS, compilation and possible
failure with a MethodTooLargeException (maybe hidden in another
Throwable) which we also want pretty-printed to be actionable
for a pipeline developer.
Signed-off-by: Jim Klimov <[email protected]>
…fter refactoring out of earlier codebase Also avoid the final if/else to have a clear final code path Signed-off-by: Jim Klimov <[email protected]>
…rt exception with a curated message to go into job log, chop off the stack trace leading to the reporter Signed-off-by: Jim Klimov <[email protected]>
…clude x.getMessage(), a copy is already there Signed-off-by: Jim Klimov <[email protected]>
…ationErrorsException.getMessage() is too long with all the original stack trace Introduce an xMsgStart with curated start of original Throwable's message (until the first "\tat somewhere(file:line)" match). Signed-off-by: Jim Klimov <[email protected]>
…ee in pretty-printed overflowedClassName Signed-off-by: Jim Klimov <[email protected]>
…SNAME_PATTERN and CLASSNAME_MENTIONS_PATTERN expectations/assumptions in code Signed-off-by: Jim Klimov <[email protected]>
…e may have slashes for class or not for step Signed-off-by: Jim Klimov <[email protected]>
…ine scripts named like "Script<NUM>" Signed-off-by: Jim Klimov <[email protected]>
…excerpts into snip-markers to separate visibly Signed-off-by: Jim Klimov <[email protected]>
…eMsg as a StringBuilder Signed-off-by: Jim Klimov <[email protected]>
…dClassNameBreadcrumbs as a StringBuilder Signed-off-by: Jim Klimov <[email protected]>
…verflowedClassName for overflowedClassNameBreadcrumbs Signed-off-by: Jim Klimov <[email protected]>
…excerpts - only add a newline before final wrapper if not present in wrapped text Signed-off-by: Jim Klimov <[email protected]>
…eraction" with ContinuationGroup.fixupStackTrace() Signed-off-by: Jim Klimov <[email protected]>
…x in the end, use a dedicated "RuntimeException rtex" object Signed-off-by: Jim Klimov <[email protected]>
…line Signed-off-by: Jim Klimov <[email protected]>
|
Updated screenshots, now with some detail learned about MTL issues happening in the JSL also:
Notably, code was made to trace the messages I've seen (and posted earlier above) with "bread-crumbs" to see the code path through the pipeline script and groovy (JSL) files and line numbers (for steps/classes with code too large), only to discover this is slapped on later via Probably some refactoring can be due to take advantage of that bit. At least, the groovy-cps code is now in the same plugin. |
…ding for logged message Signed-off-by: Jim Klimov <[email protected]>
A small almost-cosmetic change which makes life easier for my colleagues when they develop (and debug failures of) Jenkins scripted pipelines.
UPDATE: Grew to be not so small, so evicted into a method of its own to constrain changes to other parts of the codebase. Learned a few more tricks over time, as new MTL situations were found in the field.