In hindsight it might have better to split this into two separate plugins but at the time it was our understanding that Atlassian was moving to consolidate both the branding and API specification of Cloud and Server. The implementation would still be separate but the specification was supposed to merge to be much more similar. These things obviously take longer than expected but afaik that is still their plan. I would love it if Bitbucket Server would provide webhooks out of the box like Bitbucket Cloud does.
Given where we are now I think splitting the plugins will take more work, create more overlapping code, and cause more user confusion than is necessary. If all of their jobs suddenly stopped working users would be pretty pissed. I think the refactor suggestions above are fine and leave it to you and Stephen to figure out. However, I think we need a default webhook plugin to test with and include in the bitbucket-branch-source plugin. We can create an extension point to register other webhook providers but we shouldn't break anything for existing users. It would be nice we either consolidate on one webhook source or we agreed on the minimum JSON payload that would be provided by each. On Mon, Mar 13, 2017 at 12:35 AM, 'Robin Müller' via Jenkins Developers < [email protected]> wrote: > Hi > > Am Sonntag, 12. März 2017 21:50:01 UTC+1 schrieb Stephen Connolly: >> >> >> On Sun 12 Mar 2017 at 18:23, 'Robin Müller' via Jenkins Developers < >> [email protected]> wrote: >> > ... >> > Not everyone in the OSS community has the luxury of somebody who can pay >> to get licenses for these and set up multiple Bitbucket server instances to >> allow testing the different server plugins. >> >> If we add support for more we effectively push others in the OSS >> community out of the ability to contribute. >> > > This wouldn't be an issue if the add-on specific code is moved to a > different Jenkins plugin. Just have a look at this > <https://github.com/coder-hugo/bitbucket-server-branch-plugin/tree/master/src/main/java/org/jenkinsci/plugins/bitbucket/server/webhook>, > how it can work. > > If we leave the support for both Bitbucket Cloud and Bitbucket Server > within the "Bitbucket Branch Source" plugin I'd suggest the following > changes to improve the maintainability: > 1. implement a BitbucketCloudSCMSourceNavigator and a > BitbucketServerSCMSourceNavigator that share the same base class but have > the tool specific implemented in itself (e.g. retrieving the correct client > implementation). With this you don't need to distinguish based on the URL > or some other user provided input whether to talk to Bitbucket Cloud or > Bitbucket Server. You'll always know this information depending on the > context. > 2. Do the same for the SCMSource > 3. Replace the current "REST client implementation" by using JAX-RS (see > BitbucketServerAPI.java > <https://github.com/coder-hugo/bitbucket-server-branch-plugin/blob/master/src/main/java/org/jenkinsci/plugins/bitbucket/server/api/BitbucketServerAPI.java> > , BitbucketServerClientService.java > <https://github.com/coder-hugo/bitbucket-server-branch-plugin/blob/master/src/main/java/org/jenkinsci/plugins/bitbucket/server/client/BitbucketServerClientService.java>). > The current implementation is error-prone. E.g. URLs get generated using > String.fromat which means you have to care for proper URL encoding of path > parameters yourself. You have to map status codes of error responses > manually to exceptions. JAX-RS does this out-of-the-box. And last but not > least. JAX-RS provides an easy way to read the whole request/response to > add it the the log (see LoggingFilter.java > <https://github.com/coder-hugo/bitbucket-server-branch-plugin/blob/master/src/main/java/org/jenkinsci/plugins/bitbucket/server/client/LoggingFilter.java>) > which is very useful if some request failed. > > I know that 1. and 2. will lead to some migration effort but this can be > done automatically by the plugin within an initialisier. I did something > similar already within the gitlab-plugin. > > I don't know how your time schedule looks like but if you like I can > support you reaching the above points. But as not everything of the plugin > is covered by tests it could take some time to be sure I don't break any > existing functionality. > Nevertheless I'll install my plugin for the moment in our Jenkins as this > is working with our Bitbucket Server and will save the whole department a > lot of time. > > Regards, > Robin > > -- > 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/85b5ac9b-b3b5-4063-8676-0418fb784607% > 40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/85b5ac9b-b3b5-4063-8676-0418fb784607%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Patrick Wolf Product Director - Jenkins CloudBees -- 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/CAGDV0P_mA9ZncbcBaxmV9hWa-UyguQx7PHVEPQOSrr%3DvNX-xKw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
