Extend Simple Parameterized Build Report

[Jacqueline Taing]

I have already reached out to maintainer but posting this here as well per best practices on plugin extension.

I would like to extend/make changes to Simple Parameterized Build Report plugin to meet our needs.  It changes the behavior of the plugin pretty significantly.  

Here are the changes I need:

1. Limit number of parameterized builds and jobs for each build to a certain time (e.g. only show those started in last 2 weeks)  The builds we are showing in the report are build flows that trigger regression tests.  Tests are triggered either nightly and weekly.  The table can easily get very large and clutters what the team needs to focus on.
   
2. Change the URL text shown in each cell to include build time and build duration. Currently, report shows build.displayName, which is very useful for us since it's just the build number.  We also wanted to add build duration to see if we there regressions in test run times vs. earlier test run.
3. Change URL to navigate to test results.  Our test runs use the Build Flow Test Aggregator to aggregate JUnit XML results from each test job triggered by the build flow.  This provides more information on what tests were run, what failed, etc.
4. Add text that shows QA acceptance status in each cell.  We are using this report to determine if a build is good enough.  The way we are doing this is that after test run analysis is complete, build description is updated with appropriate status.
   
5. Change color of each cell based on QA acceptance comments. We need a way to still mark a build as "green" even if tests failed since they could have failed due to known issues or due to test environment issues.  The build description will have some formatted comments that will determine what color the cell will be. 

I also would like to change the name to Build Quality Report to match what the report is showing.  

The plugin does not have any licensing information.  I'm assuming based on docs that this is MIT license.

What is the best way to proceed?

Thanks!

-jacqui

[Baptiste Mathus]

IANAL, but I think you assume wrongly. Looking at the code, this is IMO typically a bad case of non licensing. And beware that by default, accessible code doesn't mean open source. Quite the contrary actually. If you don't specify anything (but ianal, again) then you retain all the copyright (i.e. the code is proprietary).

If I'm right here, btw, I'm wondering how many Jenkins plugins suffer from this issue.

What is the best way to proceed?

IIUC your request, IMO there's two way of achieving your needs:

• try to make your changes accepted upstream through many dedicated pull-requests. Or even ask to become the maintainer is the current one has given up. In that case, though, you should better thrive to make your changes backwards-compatible. Or if impossible, use that https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions to specify you're breaking some things. But IMO that should be the last resort.
  
• forking in a private plugin and just code what you need
  

 

HTH

--

Baptiste