search

AmadeusITGroup / sonar-stash

Stash (BitBucket) plugin, a pull-request decorator which allows to integrate SonarQube violations directly into your pull-request
MIT License
165 stars 82 forks source link

Questions about the future of the project #202

Open carlspring opened 5 years ago

carlspring commented 5 years ago

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:

Please advise! Many thanks in advance!

Martin

t-8ch commented 5 years ago

Hi Martin,

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

carlspring commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 https://github.com/AmadeusITGroup/sonar-stash/issues/202?email_source=notifications&email_token=ADB4Q5YS5UTTDADAURNN3H3PZPCHZA5CNFSM4HPLA3T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWFZI#issuecomment-500130533, or mute the thread https://github.com/notifications/unsubscribe-auth/ADB4Q57WBKYXGO3MSG75WP3PZPCHZANCNFSM4HPLA3TQ .

carlspring commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

4n4n4s commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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