Administrators would benefit from a feature to download job bundle, build bundle, node bundle directly from the Jenkins UI. Those information are required to troubleshoot issues related to build / node failures or job / node configuration. While those can be retrieved from the file system, it would be really useful to b able to get this from the UI and also leverage anonymization of the Support Core.

• Run Action to download Run information (build.xml, build logs, other files and directories)
• Item Action to download Item information (config.xml, other files and directories)
• Computer Action to download Node / Computer information (config.xml, remote working dir, remote logs, ...)

As a Jenkins administrator, I would like to be able to click on a "Support" button for a build, a job, a folder, a node and generate a bundle which contains the contents of the item that I'm concerned about. When I click on this button, I'm prompted to select what I which to include from the item with relevant default selection.

Acceptance

• Administrators shall see a new Support menu option on each Build, Item, Node (except master) page.
• The Action shall only be available to users with sufficient permission on that item
• The Action layout shall resemble the one of the root action
• The bundle generation shall leverage the current anonymization model
• The bundle generated shall contain a manifest
• The user shall be able to select an option to add files from object root directory
• The user shall be able to includes / excludes object root directory files from the bundle generation (Ant Style pattern)
• The Menu option(s) to download content from the file system will only be available to users with Jenkins.ADMINISTER (or could be Jenkins.RUN_SCRIPTS) permission
• The user shall be presented with meaningful / non performance impacting defaults (For example, when getting content of a top level item, do not allow defaults that would download the entire root directory)
• For Nodes, the user shall be able to select an option to add files from the remote working directory
• For Nodes, the user shall be able to includes / excludes remote work dir files from the bundle generation (Ant Style pattern)
• For Nodes, the user shall be able to select options that exists in the Root action:
  • Agent System Properties
  • Agent System Configuration (Linux only)
  • Agent JVM System Metrics
  • Agent Config file
  • Agent Logs
  • Agent Launch Logs
  • Agent Command Statistics
  • Networks Interfaces
  • File Descriptors
  • Thread Dump
  • Environment Variables
  • Dump Export Table
  • Root CAs

Design

New type of Component

• Abstract class ObjectComponent with generics for extensions of Actionable (or AbstractModelObject ?) items that implements a Describable (need components more complex than just a checkbox).
  • An ObjectComponent defines an abstract method to add contents for a specific object (maybe addContents(Container, T)).
  • An ObjectComponent defines a method applicable(T), true by default but not final, to indicate if the component is applicable to the object processed.
  • An ObjectComponent defines a method isSelectedByDefault(T), true by default but not final, to indicate if the component should be selected by default for the object processed
  • ObjectComponent shall extend Component
    • To be able to leverage existing model
    • To have components that may be used at both Root and Object(s) level
    • (Also it does make sense in terms of architecture: an ObjectComponent is a Component with extra capabilities, or this could be done with interfaces instead ?)
    • addContents(Container) inherited from }} Component shall be a no-op by default. Could be overridden for {{Component}}s that apply to both Root and a specific object. In most of those cases the {{addContents method would probably reuse the ObjectComponent#addContents(Container, T) in a loop.

New Actions "API" for Object

• Abstract class SupportObjectAction with generics for extensions of Actionable (or AbstractModelObject ?) items
  • Should provide most of the method required for stapler (like getting applicable descriptor and components and the defaults)

New Components for Directory content

• A component that has an includes / excludes field, and can retrieve root directory content for a specific class of object, extension of Actionable (or AbstractModelObject?).
• A component that has an includes / excludes field, and can retrieve remote working directory content for a specific Node.
• Add a reusable writeBundle method that accepts a "consumer" of Component. This consumer should have a method that pass the Container such as visit(Container, Component).
  • The object actions would pass consumers that append content using ObjectComponent#addContents(Container, T).
  • The root action would pass a consumer that appends content using the existing Component#addContents(container).

Existing API changes

• SupportAction (Root action) should not accept all extensions anymore, only the applicable ones
• Component should have a method isApplicable(Class) to indicate if it is applicable to a specific class of item. Should be applicable to Jenkins by default.
• writeBundle should reuse a new method that accepts a consumer of Component.
• Existing Component that can be applied at object levels may need to be extending the more specific class ObjectComponent, have a DataBoundConstructor annotated constructor and a descriptor. Another solution, that avoid modifying, is to create a components and duplicate a bit of code.

(Note: The design should also enable to add functionality to generate bundle for list of nodes and items, and why not all combined in the same archive. In that regards, it is important that the location of the appended content in the bundle do not clash between (all) components. For example, a component that retrieve content within the root directory of nodes should be located under nodes/slave/<slaveName>/. A component that retrieve this for an item or a build may be under items/<itemFullPath>/.)

Testing

Code:

• For each new action, integration test of Action URL via HTTP request
• For each new component, unit tests

Integration:

• Environment: Jenkins LTS 2.138.1
• Environment: Jenkins LTS 2.138.1 with a dependent like CloudBees Jenkins Advisor
• Environment: Jenkins latest LTS
• Environment: Jenkins latest LTS with a dependent like CloudBees Jenkins Advisor