Questions about the future of the project

[carlspring]

Hi,

We are considering using your plugin against a 6.7.6 instance of Sonarqube. At some point later this year in Q3, or Q4 we will get upgrade to version 7.x.

I would like to ask you for a clarification of the following statement:

Important note
Version 7.7 of SonarQube dropped support for the extension point sonar-stash uses. This means this plugin can not work on SonarQube versions >= 7.7. Therefore the 1.6.0 release is the last feature-release of sonar-stash.

Does this mean that this plugin will no longer be developed, or does it mean that it will no longer be developed against ths 7.x branch of Sonarqube?

If you will no longer be developing this plugin, would you mind clarifying:

• What this would mean for people who would like to contribute fixes back?
• What will happen to the existing unmerged PR-s?
• If you know of an alternative plugin for this?
• If we were to fork the project and add support for the new end-points + some authentication fixes that we might need, would you consider merging this back?

Please advise!
Many thanks in advance!

Martin

[t-8ch]

Hi Martin,

Yes, the development of the plugin has effectively stopped (except if a severe is found)

• If it is indeed a bug fix it will be reviewed/merged
• These are mostly Quality-of-life improvements and special features. They won't be merged anymore.
• Only the SonarSource-provided "Branch" plugin will be able to provide this functionality properly. (You will need to buy one of the paid versions of SonarQube for this)
• Which endpoints and authentication fixes are you talking about? Afaik there is no way to make this plugin work with new SonarQube 7.7 (this is the core reason, development has been stopped)
  If you create a well-maintained fork I would probably add a note to the README pointing to it.

[carlspring]

Hi Thomas,

Thanks for getting back to me and for providing these details!

Would you mind elaborating on what exactly is breaking (classes, end-points and so on), so that perhaps other developers, (or ourselves), can get a better understanding of what will have to be done, if we'd like to "revive" the project? An outline of the issues and the classes to look into would be really helpful.

Thanks for your time!
Kind regards,

Martin

[t-8ch]

You can try to use the plugin with SonarQube 7.7 to observe the following behaviour:

The plugin is implementing an extension point that is run after the normal analysis (PostJob).
Then it iterates over all the found issues and reports them to Stash/Bitbucket.
Retrieving the issues is not possible anymore: https://github.com/SonarSource/sonarqube/blob/857c27b744321ddbdd7dbc12e761ee11b83e6288/sonar-scanner-engine/src/main/java/org/sonar/scanner/postjob/DefaultPostJobContext.java#L57
Also no other extension point seems to provide the right data sonar-stash needed.

[tonyfalabella]

I would just like to commend you and your team for this plugin. I've gotten dozens of teams within my large organization to use the tool and it's proven to be extremely helpful. I've glanced a few times at the Enterprise offering SonarSource will provide and my fear it that it won't be as robust as your offering. Our firm does have an Enterprise license from SonarSource but currently they're on a very old version of the tool (5.6). I guess we'll see how things look when they finally upgrade to 7.x later this year.

In any event I just wanted to thank you for creating this and open-sourcing it for the community. Cheers!

[timothydowney]

I'll second that. It's been a great plugin and has really helped drive many teams in our Enterprise to really understand the value of pull request based development.

…

On Sat, Jun 8, 2019 at 10:58 AM Tony Falabella ***@***.***> wrote: I would just like to commend you and your team for this plugin. I've gotten dozens of teams within my large organization to use the tool and it's proven to be extremely helpful. I've glanced a few times at the Enterprise offering SonarSource will provide and my fear it that it won't be as robust as your offering. Our firm does have an Enterprise license from SonarSource but currently they're on a very old version of the tool (5.6). I guess we'll see how things look when they finally upgrade to 7.x later this year. In any event I just wanted to thank you for creating this and open-sourcing it for the community. Cheers! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#202?email_source=notifications&email_token=ADB4Q5YS5UTTDADAURNN3H3PZPCHZA5CNFSM4HPLA3T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWFZI#issuecomment-500130533>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADB4Q57WBKYXGO3MSG75WP3PZPCHZANCNFSM4HPLA3TQ> .

[carlspring]

I've been wondering how such plugins can move forward. I've commented on SONAR-11670. I think there should be some sort of push back from the community and more people should raise their concerns that SonarSource's current approach will kill off a lot of plugins.

Would it make sense to create a separate plugin that contains the preview mode functionality, so that plugins like the sonar-stash one could keep working with Sonarqube > 7.7?

[t-8ch]

Not sure how the preview functionality itself could be implemented in a plugin.
Only predefined extension points can be implemented by plugins and none of them match this usecase.

[jakub-bochenski]

I was wondering if anybody considered using whatever sonarlint is using?
Sonarlint is able to do local analysis, it works differently but the aims are the same as with the old preview mode.

How hard could it be to look at e.g. Sonarlint-Eclipse plugin and make it just print a list of issues to a file instead of reporting them via the Eclipse API? If it can work in IDE it can work in a batch job/CI build

[t-8ch]

@jakub-bochenski Thanks for taking a look how the gitlab plugin handles this!

Also the idea with sonarlint is quite interesting. I see the following problems:

Sonarlint is a new launcher for the scanning engine. If we create our own we will loose all support for the existing maven/gradle/etc runners.

TBH as we are not using the plugin ourselves anymore (it got replaced by the official branch plugin) any major rework would have to be done by somebody else.
It would probably make sense to collaborate with the gitlab plugin team on creating a common launcher for this kind of plugin and use this from both projects.

[jakub-bochenski]

Sonarlint is a new launcher for the scanning engine. If we create our own we will loose all support for the existing maven/gradle/etc runners.

I'm aware. I have some familiarity with Maven plugins though, I can certainly volunteer to do that part if other pieces fall into place. Another alternative would be to just have a standalone runner.

It would probably make sense to collaborate with the gitlab plugin team on creating a common launcher for this kind of plugin and use this from both projects.

Could you maybe ping them in the linked issue too? Don't want to spam, but a comment from the official maintainer might get more attention.

[carlspring]

It would be a shame to stop developing this plugin. I've worked for a few companies where this plugin is this in use.

It's sad that Sonarsource have made this decision. However, it seems that there are many bright people out there who would like to keep this project kicking. Perhaps we could gather a list of options that we could investigate and start working on them? Perhaps, it would indeed make sense to create some common functionality for Stash and Gitlab? Perhaps it would make more sense to create a generic new plugin for reporting to a git repository and could use a provider for each of these implementations that would handle the HTTP requests to the respective service. I mean -- the concept is the same -- get all the issues and report them to the Git hosting service. (Of course, each of these services has their own quirks, but I think it would make more sense to sort of merge the common functionality and handle the publishing in the pull requests through the respective "provider" implementation).

What do you guys think?

[t-8ch]

Well, the code is all here.
Feel free to use a ticket in sonar-stash to coordinate any further development.
If something is going to come from it, it should be developed as it's own dedicated project (not as part of sonar-stash).
I am happy to point to it from here.

[jakub-bochenski]

I agree starting a fresh project will probably be better.
Coordinating with gitlab-plugin can be helpful, but since they haven't committed to anything I think it's safer to start independently and offer them to join forces if/when they want to.

Of course, each of these services has their own quirks, but I think it would make more sense to sort of merge the common functionality and handle the publishing in the pull requests through the respective "provider" implementation

Personally I would start by dumping the list into json/xml/yaml file.
Then you can use your scripting language and http client of choice to post them via REST API

[t-8ch]

I would advise to stick with java or a jvm-based language, because that is the only thing to be guaranteed to exist where SQ is executing.

[carlspring]

I would advise to stick with java or a jvm-based language, because that is the only thing to be guaranteed to exist where SQ is executing.

I wouldn't do it in any other language.

[jakub-bochenski]

For the part that does analysis Java is probably the choice.
However (and this is just to make the first version easiest) in my idea the second part is left as an exercise to the user. It's so much easier to hack something together that works for you, instead of writing robust client code that can handle multiple versions etc.

I know we can probably reuse the code here, but still dumping to file is easier that reusing code :)

EDIT: another way to put it is: I would make file dump the first "provider" type

[jakub-bochenski]

Maybe this plugin would be useful https://github.com/mc1arke/sonarqube-community-branch-plugin

[4n4n4s]

@jakub-bochenski @t-8ch I helped to develop the mentioned plugin a little bit it would be nice to get your feedback if it's working for your company / projects.

Currently the release jar is still 1.2.0 which does not contain the pr decoration you need to ./gradlew clean build as written in the readme.

[jakub-bochenski]

@4n4n4s we are still using a version that keeps the old API as our production instance, so I don't have much to share unfortunately

[t-8ch]

@4n4n4s We switched to the built-in decoration of SQ 8, so unfortunately I can't really give you feedback, sorry.