2015-09-01 19:25 GMT+02:00 Jacqueline Taing <[email protected]>: > I have already reached out to maintainer but posting this here as well per > best > practices on plugin extension > <https://wiki.jenkins-ci.org/display/JENKINS/Before+starting+a+new+plugin#Beforestartinganewplugin-maintainer> > . > > I would like to extend/make changes to Simple Parameterized Build Report > plugin <https://github.com/nullin/simple-parameterized-builds-report> 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 > > <https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Test+Aggregator+Plugin> > 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 > <https://wiki.jenkins-ci.org/display/JENKINS/Before+starting+a+new+plugin#Beforestartinganewplugin-maintainer> > that this is MIT license. >
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 -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4RWpitq%2BSoZ8wwcTH%3DPuoFCp%3DW6Le42eP%3D7ObXGn_fbQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
