On 06/11/2019 23:01, Eric Ball wrote:
>
> You can view the OpenDaylight Sonarcloud page
> here: https://sonarcloud.io/organizations/opendaylight/projects
> Currently, the only projects showing results are those that have run and
> passed on the sandbox. Once the change is merged, all projects will show
> results after their next successful run.
>
> You may notice that while quantitative numbers like code coverage and
> duplication haven't changed, the number of bugs/vulnerabilities/code
> smells may have changed significantly (most likely an increase). This is
> due to Sonarcloud using much more up-to-date Quality Profiles than ODL's
> SonarQube instance, so this should be considered an improvement in
> results (even though I understand that it can be a pain to suddenly have
> a backlog of issues where there were few or none before). These profiles
> can be customized, so if anyone sees something coming up that absolutely
> should not be in the results, we can remove it from the Quality Profile.
>
> Please let me know if you have any questions, or if you'd like to bring
> this up for discussion during the next TSC meeting.

Another thing: there seems to be no historical data available. I would
hate to lose the 4+ years of data accumulated in
https://sonar.opendaylight.org/dashboard?id=org.opendaylight.yangtools%3Ayangtools-aggregator.

What is being done about that?

Regards,
Robert

Hello all,

We here at the LF Release Engineering team are working on a move from hosted SonarQube instances to the cloud-based Sonarcloud service. To that end, there is currently a proposed change to all Sonar jobs that would move them to Sonarcloud: https://git.opendaylight.org/gerrit/c/releng/builder/+/85644

Sonarcloud has more features and better language support than SonarQube, and it will remove the hosting and maintenance costs associated with the SonarQube server. Our plan is to decommission the SonarQube server about a month after we make the move to Sonarcloud.

You can view the OpenDaylight Sonarcloud page here: https://sonarcloud.io/organizations/opendaylight/projects

Currently, the only projects showing results are those that have run and passed on the sandbox. Once the change is merged, all projects will show results after their next successful run.

You may notice that while quantitative numbers like code coverage and duplication haven't changed, the number of bugs/vulnerabilities/code smells may have changed significantly (most likely an increase). This is due to Sonarcloud using much more up-to-date Quality Profiles than ODL's SonarQube instance, so this should be considered an improvement in results (even though I understand that it can be a pain to suddenly have a backlog of issues where there were few or none before). These profiles can be customized, so if anyone sees something coming up that absolutely should not be in the results, we can remove it from the Quality Profile.

Please let me know if you have any questions, or if you'd like to bring this up for discussion during the next TSC meeting.

Note: ovsdb is using a custom Sonar template. This will need to be changed to work with Sonarcloud, or (preferably) changed to use global-jjb templates. If there's something our global-jjb jobs do not currently support, we should be able to add that functionality.

Eric Ball

Release Engineer

The Linux Foundation

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12181): https://lists.opendaylight.org/g/TSC/message/12181
Mute This Topic: https://lists.opendaylight.org/mt/44622856/1278122
Group Owner: TSC+owner@...
Unsubscribe: https://lists.opendaylight.org/g/TSC/unsub  [abelur@...]
-=-=-=-=-=-=-=-=-=-=-=-

Hi Abhijit: 

Please add this thread to the week's TSC call agenda and possibly take a vote on this. 

1. ODL Projects needs to vote (+1) before each of these change can be merged on releng/builder.

    https://git.opendaylight.org/gerrit/c/releng/builder/+/85644

2. Agree upon a time when Sonarcube (https://sonar.opendaylight.org) can be decommissioned. Please note, Sonarcloud has better features and language support than SonarQube, and also remove the hosting and maintenance costs associated with the SonarQube server.

Thanks,

Anil

On Thu, Nov 7, 2019 at 8:02 AM Eric Ball <eball@...> wrote:

Hello all,

We here at the LF Release Engineering team are working on a move from hosted SonarQube instances to the cloud-based Sonarcloud service. To that end, there is currently a proposed change to all Sonar jobs that would move them to Sonarcloud: https://git.opendaylight.org/gerrit/c/releng/builder/+/85644

Sonarcloud has more features and better language support than SonarQube, and it will remove the hosting and maintenance costs associated with the SonarQube server. Our plan is to decommission the SonarQube server about a month after we make the move to Sonarcloud.

You can view the OpenDaylight Sonarcloud page here: https://sonarcloud.io/organizations/opendaylight/projects

Currently, the only projects showing results are those that have run and passed on the sandbox. Once the change is merged, all projects will show results after their next successful run.

You may notice that while quantitative numbers like code coverage and duplication haven't changed, the number of bugs/vulnerabilities/code smells may have changed significantly (most likely an increase). This is due to Sonarcloud using much more up-to-date Quality Profiles than ODL's SonarQube instance, so this should be considered an improvement in results (even though I understand that it can be a pain to suddenly have a backlog of issues where there were few or none before). These profiles can be customized, so if anyone sees something coming up that absolutely should not be in the results, we can remove it from the Quality Profile.

Please let me know if you have any questions, or if you'd like to bring this up for discussion during the next TSC meeting.

Note: ovsdb is using a custom Sonar template. This will need to be changed to work with Sonarcloud, or (preferably) changed to use global-jjb templates. If there's something our global-jjb jobs do not currently support, we should be able to add that functionality.

Eric Ball

Release Engineer

The Linux Foundation

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12181): https://lists.opendaylight.org/g/TSC/message/12181
Mute This Topic: https://lists.opendaylight.org/mt/44622856/1278122
Group Owner: TSC+owner@...
Unsubscribe: https://lists.opendaylight.org/g/TSC/unsub  [abelur@...]
-=-=-=-=-=-=-=-=-=-=-=-

On 13/11/2019 01:28, Anil Belur wrote:
> Hi Abhijit: 
>
> Please add this thread to the week's TSC call agenda and possibly take a
> vote on this. 
>
> 1. ODL Projects needs to vote (+1) before each of these change can be
> merged on releng/builder.
>     https://git.opendaylight.org/gerrit/c/releng/builder/+/85644

That patch has been abandoned for a per-project migration (on Andy's
request).

Furthermore, as I noted in the review, we really should duplicate the
sonar jobs, so we can actually evaluate how the projects work with
SonarCloud before ...


> 2. Agree upon a time when Sonarcube (https://sonar.opendaylight.org
> <https://sonar.opendaylight.org/>) can be decommissioned. Please note,
> Sonarcloud has better features and language support than SonarQube, and
> also remove the hosting and maintenance costs associated with the
> SonarQube server.

... we decide on this.

Regards,
Robert



>
> Thanks,
> Anil
>
> On Thu, Nov 7, 2019 at 8:02 AM Eric Ball <eball@...
> <mailto:eball@...>> wrote:
>
>     Hello all,
>
>     We here at the LF Release Engineering team are working on a move
>     from hosted SonarQube instances to the cloud-based Sonarcloud
>     service. To that end, there is currently a proposed change to all
>     Sonar jobs that would move them to
>     Sonarcloud: https://git.opendaylight.org/gerrit/c/releng/builder/+/85644
>
>     Sonarcloud has more features and better language support than
>     SonarQube, and it will remove the hosting and maintenance costs
>     associated with the SonarQube server. Our plan is to decommission
>     the SonarQube server about a month after we make the move to Sonarcloud.
>
>     You can view the OpenDaylight Sonarcloud page
>     here: https://sonarcloud.io/organizations/opendaylight/projects
>     Currently, the only projects showing results are those that have run
>     and passed on the sandbox. Once the change is merged, all projects
>     will show results after their next successful run.
>
>     You may notice that while quantitative numbers like code coverage
>     and duplication haven't changed, the number of
>     bugs/vulnerabilities/code smells may have changed significantly
>     (most likely an increase). This is due to Sonarcloud using much more
>     up-to-date Quality Profiles than ODL's SonarQube instance, so this
>     should be considered an improvement in results (even though I
>     understand that it can be a pain to suddenly have a backlog of
>     issues where there were few or none before). These profiles can be
>     customized, so if anyone sees something coming up that absolutely
>     should not be in the results, we can remove it from the Quality Profile.
>
>     Please let me know if you have any questions, or if you'd like to
>     bring this up for discussion during the next TSC meeting.
>
>     Note: ovsdb is using a custom Sonar template. This will need to be
>     changed to work with Sonarcloud, or (preferably) changed to use
>     global-jjb templates. If there's something our global-jjb jobs do
>     not currently support, we should be able to add that functionality.
>
>     Eric Ball
>     Release Engineer
>     The Linux Foundation
>     -=-=-=-=-=-=-=-=-=-=-=-
>     Links: You receive all messages sent to this group.
>
>     View/Reply Online (#12181):
>     https://lists.opendaylight.org/g/TSC/message/12181
>     Mute This Topic: https://lists.opendaylight.org/mt/44622856/1278122
>     Group Owner: TSC+owner@...
>     <mailto:TSC%2Bowner@...>
>     Unsubscribe: https://lists.opendaylight.org/g/TSC/unsub 
>     [abelur@... <mailto:abelur@...>]
>     -=-=-=-=-=-=-=-=-=-=-=-
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12218): https://lists.opendaylight.org/g/TSC/message/12218
> Mute This Topic: https://lists.opendaylight.org/mt/44622856/1320659
> Group Owner: TSC+owner@...
> Unsubscribe: https://lists.opendaylight.org/g/TSC/unsub  [nite@...]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On Thu, 5 Dec 2019 at 12:55, Eric Ball <eball@...> wrote:

Okay, so what is the process to gain access? We have the controller
being analyzed and the number of utterly false positives is not funny
and I have no way to close them down.

To gain access, you'll need to log into Sonarcloud.io using a Github account. If your Github account is already a member of the github.com/opendaylight org, you'll immediately have access to the Sonarcloud org. If not, you can open an issue at support.linuxfoundation.org, providing your Github username for us to provide access. 

Two examples:

https://sonarcloud.io/project/issues?id=opendaylight_controller-sonarcloud&issues=AW6UsvtubRr7khNgdg70&open=AW6UsvtubRr7khNgdg70
is so utterly and completely wrong it's hard to describe -- target
object type is a simple enum, having no state, hence it all the points
about safe publication are utter BS in this context.

https://sonarcloud.io/project/issues?id=opendaylight_controller-sonarcloud&issues=AW6Usvo9bRr7khNgdg5r&open=AW6Usvo9bRr7khNgdg5r
is also utterly wrong -- there is even a
@SuppressFBWarnings(VO_VOLATILE_REFERENCE_TO_ARRAY) to mark that yes, we
really know what we are doing (it is a cache of the serialized form, and
no, we do not really care about double-checked loading).

Furthermore, what is the process to evolve the rule sets?

We can make changes to the Quality Profiles to meet the needs of the projects, if there are rules that should never be applied. Otherwise, like SonarQube, individual issues can be marked as false positives, and/or have their priority lowered.

Hi Eric,

 

I recall the old sonar system has the "ODL Sonar Way" or something profile. Can we not redo that profile in SonarCloud?

I believe that profile was crafted by the community over the years of using Sonar, it seems like if we are able to reapply the rules from there we don't have to relearn our ruleset all over again. It seems to me like a waste of time to have the community backtrack on configuration that has already been applied in the past.

Regards,

Thanh

At this point, what's still needed before we start merging these changes? I can continue to address any concerns with this, but if there isn't anything further, I'd like to start getting these changes reviewed and merged. https://git.opendaylight.org/gerrit/q/status:open+sonarcloud

On Mon, Dec 9, 2019 at 1:50 PM Robert Varga <nite@...> wrote:

On 09/12/2019 22:36, Eric Ball wrote:
> Ok, I've recreated the "ODL way" Java quality profile (59 of 60 rules;
> one was deprecated) in Sonarcloud, and set it as the default. Future
> runs should reflect only those rules that were chosen. I still think
> this should probably be updated, as it has not changed in 5 years, but
> for now the results should be closer to what you're getting in SonarQube.

Yeah, I was going to write that, but haven't gotten to it. We certainly
should take the default sonarcloud profile and re-evaluate it.

Regards,
Robert