[JENKINS-67380] Detect oversized maps, collections and arrays and truncate

[Vlatombe]

JENKINS-67380

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[Vlatombe]

This was wrong. If you do nothing then the data is unmodified.

[Vlatombe]

cc @jglick

[jglick]

Looks like it would fix the issue though I am not sure the details are right. Probably does not matter much either way.

Would prefer to fix https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/1d91c29606ce59515614ed0d7536b1aaaea9e356/src/main/java/org/jenkinsci/plugins/pipeline/utility/steps/json/WriteJSONStep.java#L55 to be a String, perhaps, though this might require some tricks with two JavaBeans attributes backed by a single field. Hard to know exactly what to do with this step because it violates the basic constraint of Pipeline steps that their arguments should be types accepted by DescribableModel: primitives (Strings, true primitives, maybe enums), or Describables and List<Describable>s with their attribute types recursively being acceptable; a Map is never legal (the stepArguments are a special case). Would prefer to just deprecate this step and others like it that deal with nonstandard types; they just cause all sorts of problems. (jenkinsci/pipeline-utility-steps-plugin#47, https://issues.jenkins.io/browse/JENKINS-49669?focusedCommentId=353921&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-353921, etc.)

The fundamental problem with the design of ArgumentsAction (as I failed to convince the author of the API at the time) is that it stores the surface form of arguments, raw from Groovy

workflow-cps-plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/DSL.java

Line 539 in fc3007f

final Map<String,Object> namedArgs;

rather than the logical form, and you need to call getResolvedArguments later and hope you can still reconstruct what was actually meant at the time the build ran. Keeping only the logical form would probably have avoided this particular issue just to the extent that there is no logical form for WriteJSONStep.json and so this map entry would simply have been discarded for purposes of ArgumentsAction.

[jglick]

Looks right. Thanks!