[NEW RELEASE] 1C (BSL) Community Plugin 1.0.1

SonarQube Plugin Development
1

Hello!

I’m proud to announce that 1C (BSL) Community Plugin is ready for public release.

Link to the sonar-update-center-properties PR: https://github.com/SonarSource/sonar-update-center-properties/pull/35

SonarSource, please, check this up, and if everything is “ok” add it to the Marketplace.

Thanks!

3 Likes
2

Hi,

It’s not clear to me how best to go about testing this. It seems I need a BSL Language Server? Either that or a pre-generated report from such a server. Do you have an example project with such a report?

 
Thx,
Ann

3

Hi, Ann!

Nope, BSL Language Server is included to plugin. You may run it separetly and import results if you want, but default behavior is to get issues from the bundled one.

Do you have an example project with such a report?

You can try to analyze any project from this github ogranization - oscript-library · GitHub

Also you can check this public server for 1c libraries - https://sonar.oscript.ru
It runs on 0.6.0 version of plugin and on 7.7 SQ version. And most of the code is on russian (it is normal for 1C (BSL)).
If you need, i can upgrade this server to 7.9 and latest release ASAP.

4

Looks like we found a critical bug in BSL LS, causes sonar-scanner to crash on some specific files. I’ll re-release plugin and post new links here.

Sorry for inconvenience.

2 Likes
5

Hi, @ganncamp!

I’ve re-released sonar plugin and updated links in first post.
PR to sonar-update-center-properties is also updated.

2 Likes
6

@ganncamp kindly reminder about this thread :slight_smile:

Thanks!

7

Hi,

I haven’t forgotten you, I’ve just gotten busy.

 
:slight_smile:
Ann

2 Likes
8

Hi,

Sorry for the delay. I’ve noted a couple things in my testing:

  • Your plugin requires Java 11 for analysis (yes, I learned this the hard way. :smile:) . On the SQ side, Java 11 is required to run the server, but Java 8 is still allowed for analysis. Since your requirements are a bit ahead of the standard, you should probably mention that in your docs. (At least in the English version my page search for ‘Java’ came up empty.)

  • I also see that you’ve written your rule descriptions in markdown. That doesn’t do what you think it does inside SonarQube:
    Selection_593

  • I happened to notice this in your docs:

    # Filters for inclusion in the analysis. In the example below - only bsl and os files.
sonar.inclusions=**/*.bsl, **/*.os

    It made me go looking for the language-specific settings. You won’t be surprised to learn I came up blank. (Edit: Or so I thought!) It would be good in your next version to expose for user knowledge and manipulation the file suffixes you claim, like so:

    Selection_594
    Selection_594.jpg867×288 33 KB

    This is standard and allows the user to handle clashes, weird naming conventions, and extensions gracefully. Generally this is exposed in a category named for the language at both the global and project levels.

  • After writing all that ^ (sorry, I’m too lazy to re-write it) I stumbled on the fact that you’ve filed your settings under External Analyzers. I believe you’ve misunderstood the intent of that category. That category holds settings for interpreting the reports for analyzers that run before, not as part of, analysis. That’s not what your plugin provides, so you should move these settings into the language-named category I suggested you create in the previous bullet point.

  • Speaking of those settings, I’m happy to have found the language toggle. If you’re going to make Russian the default language (Totally, cool. Makes sense in the context) please at least add something to the English docs that points you to the ability to change the language. Okay, yes, I see the command-line arg documented, but IMO this sort of thing is better done “permanently” via the UI. (And bravo - and thanks! - for providing minimum i18n out of the box!)

All that said, none of those points are deal breakers. So… You’re in!

 
:slight_smile:
Ann

3 Likes
9

My birthday is just next week, but this is a great gift! Thank You!

3 Likes
10

Hi, Ann!

First of all I want to say big “Thank you” for your feedback and publishing process! :slight_smile:

I saw that SonarSource recommends to target to Java 8 for plugins. We don’t use any new shiny features from Java 11 (yet), so we can downgrade requierements to 8. But how java 11 will become popular if no-one use it? :slight_smile:
Do you (SonarSource) have any plans to drop support of Java8 for extensions? This year may be?

Also latest sonar-scanner already requires Java11 to run.

Yeah, I know about this behavior on SQ side. I even wrote a small converter for common cases :slight_smile: https://github.com/1c-syntax/sonar-bsl-plugin-community/blob/757fd6fe8ea4adea4ed02da5717c4d6233b3b25b/src/main/java/com/github/_1c_syntax/sonar/bsl/language/BSLLanguageServerRuleDefinition.java#L137-L145

Any ways to render tables in SQ Markdown flavour? (I’ve seen the docs, but i could miss something). May be any plans to migrate to some common md-library?

And about this rule description - we’ll format table with spaces so users could see it correctly without md-rendering.

It’s not about file suffixes, but related to source files of 1C:Enterprise. Source code of full 1C:Enterprise program contains a lot of generated XML files (metadata, forms, db schemas and so on), that should not be analyzed by SonarQube. So this is some kind of speed-up trick.

But I see, that I’ve forgotten to add file suffixes property at all (or drop it on some early iteration of development)

Yeah, some properties placed there from time when there was no included analyzer and the only way to import issues was sonar.bsl.languageserver.reportPaths, but know it’s not true. Thanks, we’ll move most of the properties to separate category.

Sure!

This is not obvious but diagnosticLanguage configured at Application level gives you rule names and rule descriptions and default issues messages language. Project level config gives you a way to override only issues messages, cause you can only change rules on server startup. Aaaand it should be documented too.

Once again, thanks for you help and sorry for big message :slight_smile: We’ll fix all of mentioned issues to next release.

11

Hi,

We’re moving in the direction of Java 11 (altho I can’t give you a timeline right now). That’s why I only asked that you add something in the documentation rather than making changes in the plugin.

Sorry, you’ll have to convert them to HTML if you want them properly rendered as tables. On this topic, I wrote a Jira markdown → HTML converter that we use internally to produce the HTML rule descriptions in the plugin, but it’s closed source because… reasons. :-/

I know nothing about 1C projects, but your doing this assumes that such projects won’t contain other languages…? It might be more future-proof to handle it via exclusions instead, but that’s just a thought.
 

Anyway, happy early birthday and welcome to the Marketplace!

 
:slight_smile:
Ann

12

It’s okay, i’ll try to find some md-html converter as gradle plugin.

Most of. Also this doc is just a quick-start for many and many 1C programmers that knows completly nothing about SQ (and often even about git… :frowning: ).

Thanks again!

Until next time :slight_smile: