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.
h3. 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
h3. Design
h4. 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.
h4. 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)
h4. 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)}}.
h4. 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>/}}.)_
h3. 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
|
|
|
