[VOTE] Release Build Breaker Plugin 2.0

[mjdet...@gmail.com]

Hello everyone,

I'd like to release Build Breaker Plugin 2.0.  This release is a complete rewrite of the quality gate breaker to use the recommended SonarQube 5.3 web service API workflow as a PostJob step.

Overview of changes:

• Upgrade OSS parent to 26 and Plugin API to 5.3
• Rewrite quality gate breaker to use web service API workflow (with additional configuration parameters)
• Cut dependency on commons-lang (replace with Guava, already included as transitive dependency)

Complete changelog:

https://github.com/SonarQubeCommunity/sonar-build-breaker/compare/1.1...2.0-rc1

Tag with artifact for test:

https://github.com/SonarQubeCommunity/sonar-build-breaker/releases/tag/2.0-rc1

Documentation (Confluence will require update):

https://github.com/SonarQubeCommunity/sonar-build-breaker/blob/2.0-rc1/README.md

Vote will be open for 72 hours.

Thanks,

Matthew DeTullio

[G. Ann Campbell]

Well, it broke my build. :-)

Ann


On Monday, 1 February 2016 15:06:25 UTC-5:

[Fabrice Bellingard]

Hi Matthew,

Small detail but worth mentioning this: as this plugin is now a community one, it should not use the "org.sonarsource" prefix for its groupId. Simon is currently preparing a PR so that you can apply it before the release.

Thanks!

Best regards,

Fabrice BELLINGARD | SonarSource SonarQube Platform Product Manager http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/bade1374-e171-48e5-9846-b6137322b20c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew DeTullio]

I can update it.  What is your proposal?  I don't think org.codehaus.sonar-plugins is still appropriate now that Codehaus is offline.

org.sonarsource.<name> was the only convention I had seen for projects using the new parent POMs in the community GitHub org.  I also did not see any recommendations for groupId and artifactId naming in the developer docs (http://docs.sonarqube.org/display/DEV/Your+Plugin+in+SonarQube+Update+Center).  Perhaps that page is worth updating?

Is there any other POM metadata I missed or worth updating?

Regards,
Matt

[Fabrice Bellingard]

On Wed, Feb 3, 2016 at 3:50 PM, Matthew DeTullio <mjdet...@gmail.com> wrote:

I can update it.  What is your proposal?  I don't think org.codehaus.sonar-plugins is still appropriate now that Codehaus is offline.

org.sonarsource.<name> was the only convention I had seen for projects using the new parent POMs in the community GitHub org.  I also did not see any recommendations for groupId and artifactId naming in the developer docs (http://docs.sonarqube.org/display/DEV/Your+Plugin+in+SonarQube+Update+Center).  Perhaps that page is worth updating?

Is there any other POM metadata I missed or worth updating?

Indeed Matthew, we should document this recommendation. Once Simon has provided his PR to update the POM, we'll do that!

Thanks

[Simon Brandhof]

My PR is mainly about the removal of inheritance of org.sonarsource.parent:parent. GroupId is quite verbose: "org.sonarqubecommunity.buildbreaker". It's not so important as artifacts are not deployed to Maven central repository. Feel free to use another one.

Thanks

--

Simon BRANDHOF | SonarSource
Tech Lead & Co-Founder
http://twitter.com/SimonBrandhof

[mjdet...@gmail.com]

I believe everything is sorted out regarding the transfer to the community and I will accept Ann's broken build as a +1.

Vote is now closed and I've performed the release.

Would someone on the SonarSource team kindly take the following actions?

• Add 2.0 to the Update Center
  
• Binary: https://github.com/SonarQubeCommunity/sonar-build-breaker/releases/download/2.0/sonar-build-breaker-plugin-2.0.jar
• Release notes: https://github.com/SonarQubeCommunity/sonar-build-breaker/issues?q=milestone%3A2.0
• Release summary: Compatibility with SonarQube 5.3
• Update Confluence
• Remove this page from deprecated plugins area: http://docs.sonarqube.org/display/PLUG/Build+Breaker+Plugin
• Re-add the plugin to the Plugin Library page: http://docs.sonarqube.org/display/PLUG/Plugin+Library
• Re-add the plugin to the Plugin Version Matrix page: http://docs.sonarqube.org/display/PLUG/Plugin+Version+Matrix
• 4.5 LTS, 5.0, 5.1 - version 1.1
• 5.2 - [X]
• 5.3 - version 2.0
• It may be worth mentioning the plugin on this page: http://docs.sonarqube.org/display/SONAR/Breaking+the+CI+Build

Thanks everyone!

Regards,

Matthew DeTullio

[G. Ann Campbell]

Hi Matthew,

Sorry for the delay. There has been some internal discussion, and I'm sorry to tell you that I'm not going to restore this plugin to the update center. In short, it's because we don't believe this is a viable direction.

However, I have listed the plugin on the Other Plugins page.

Thanks for understanding.

Ann

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://sonarsource.com

[Matthew DeTullio]

Thanks Ann.

This is feedback I would have appreciated ahead of time.  I invested a lot of time and effort into the quality of the plugin and being responsive to account for timezone differences, under the impression that this was going to be added.  That is why I requested a review of my original implementation.

There has been past discussion on this and I have not seen any convincing reasons as to why this functionality is not going to be supported or is a good direction.  I have dedicated my entire career to implementing software delivery pipelines and if there's anything I have learned, it is that this type of tooling is essential in large environments that are trying to shift their focus to fixing technical debt.  There is currently no alternative other than to write a custom script.  There were talks of adding build breaking functionality to the Jenkins plugin, however that only limits the ability to break the build for one type of configuration for one CI tool.  For example, using any custom build script that wraps the invocation of the scanner or even using the Gradle scanner in Jenkins would not be able to take advantage of the functionality.  This plugin covers all configurations for all CI tools and it does not compete with any SonarSource offerings.

I think that a lot of users are disappointed by the lack of this plugin in SQ 5.2+.  I've already had an issue created for this https://github.com/SonarQubeCommunity/sonar-build-breaker/issues/4 and I do not want to be in the business of repeatedly closing duplicate tickets because this is not in the update center.

I am disappointed to say the least.  In the future I hope SonarSource extends more consideration to outside contributors and to accepting contributions that fill feature gaps.

Regards,

Matthew DeTullio

[Fabrice Bellingard]

Hi Matthew,

It looks like you are pained by this decision but actually you shouldn't! You've resurrected the Build-Breaker plugin and made a new release that any SonarQube user will be able to download and install, I'm pretty sure that many people will be thankful to you for this! :-) The fact that it is not published in the Update Center is just a minor detail in the end. The plugin is here, open-source, under the SonarQubeCommunity umbrella, you have commit rights on it, anybody can contribute, and some SonarSourcers even reviewed your code/PR when you requested it (and will keep on supporting you if you need/want to). So we can't say that SonarSource prevents you from filling the gap - for the gap is actually filled! 

Best regards,

Fabrice BELLINGARD | SonarSource SonarQube Platform Product Manager http://sonarsource.com

[Michel Pawlak]

Hi,

My 2c:

• The community should decide what plugin deserves being in the update center, not only SonarSource
• Not allowing a plugin to exist in the update center, just because SonarSource has its own future plans can be understood as being a way to make community plugins less visible if they may get in your way in the future. Is it the way we should understand it ?
• The update center could be improved with concepts such as "official plugin" "community plugin" "deprecated plugin" "user should migrate to another plugin" "commercial plugin"

Michel

[Matthew DeTullio]

It would be less "painful", as you put it, if a real reason was given.  Still waiting for it...  I offered a strong, heartfelt professional opinion concerning build breaking functionality as part of the ecosystem.

Filling the feature gap for myself and the few users that patrol this mailing list, the other plugins page, and the GitHub org is hardly an accomplishment.  Offloading the plugin on to me was probably more to your benefit than to mine.

Consider taking a page from the CloudBees/Jenkins playbook, which has a successful plugin model, in addition to commercial plugins and support.

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/T8ub7NOfd2g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/CA%2BPhQbuauOS4qH26NAtSj7iS-SMP%2Bc-Pipsgt2nuX%2Bw0h5hSxw%40mail.gmail.com.

[Fabrice Bellingard]

On Wed, Feb 10, 2016 at 3:42 PM, Matthew DeTullio <mjdet...@gmail.com> wrote:

It would be less "painful", as you put it, if a real reason was given.  Still waiting for it...  I offered a strong, heartfelt professional opinion concerning build breaking functionality as part of the ecosystem.

You're right, and we're actually preparing a "strong, heartfelt professional" ;-) blog post on this because we understand and see that it's a sensitive topic. Once it's out, this will be a good basis to have an "emotion-less" discussion about this topic.

 

Filling the feature gap for myself and the few users that patrol this mailing list, the other plugins page, and the GitHub org is hardly an accomplishment.  Offloading the plugin on to me was probably more to your benefit than to mine.

Are you really sure about that? :-) Remember that we had deprecated the plugin, so it would have been far easier for us to reject your initial PR and say: "No, if you want such a plugin, do it on your own". Letting you resurrect the plugin under the SonarQubeCommunity umbrella was a proof that even if we don't believe in this feature, we don't prevent people from pushing it.

Consider taking a page from the CloudBees/Jenkins playbook, which has a successful plugin model, in addition to commercial plugins and support.

And there's just a slight difference with what CloudBees/Jenkins does: they let any plugin enter the update manager (even ones that are here just for fun) whereas we don't. But apart from that, they have a "Plugins" page that lists all the plugins so that you can find and install them manually - just like we do on our "Plugins" space.

[Fabrice Bellingard]

On Wed, Feb 10, 2016 at 1:15 PM, Michel Pawlak <michel...@gmail.com> wrote:

Hi,

My 2c:

• The community should decide what plugin deserves being in the update center, not only SonarSource
• Not allowing a plugin to exist in the update center, just because SonarSource has its own future plans can be understood as being a way to make community plugins less visible if they may get in your way in the future. Is it the way we should understand it ?
• The update center could be improved with concepts such as "official plugin" "community plugin" "deprecated plugin" "user should migrate to another plugin" "commercial plugin"

This might indeed be an evolution to consider, Michel.