[Help] Sonarqube 7.9: how to make our custom java sensor run before JavaSquidSensor?

SonarQube Plugin Development
,
1

Dear All,

We have a custom java plugin, in which we defined a custom sensor, we expect that our sensor runs before JavaSquidSensor to do some pre-scan configurations.

This all works great on sonarqube 7.6.

however recently we upgraded to sonar 7.9, but found that now JavaSquidSensor runs before our custom sensor, which makes our scan fail without configurations

we noticed that there are two new extension jars added in sonar7.9:

  • sonar-auth-github-plugin-1.5.0.870.jar
  • sonar-auth-saml-plugin-1.2.0.682.jar

removing these two jars, and restart sonar7.9, our custom sensor then runs before JavaSquidSensor as expected now. BUT we do need these two “auth” plugins there.

Please could someone kindly help here, what we shall do with Sonar7.9 to make our custom sensor runs before JavaSquidSensor, WITHOUT removing the two “auth” plugins?

Thanks a lot!

2

Add more:

I personally treat one possible fix might be related to the @DependedUpon annotation, which tells sonarqube that JavaSquidSensor should depend on our custom java sensor, but I have no idea what value I should put there, tried all below ones… none works. please kindly guide, thanks!

@Phase(name = Phase.Name.PRE)
@DependsUpon("BEFORE_SQUID")
@DependedUpon({"squid", "JavaSquidSensor", "SquidSensor", "java_squid"})
3

Hi @testmynamelist

I think your problem is that your are not correctly declaring the ordering, so the behavior is “random” (probably depends on HashMap internal order, that could explain why removing the 2 authentication plugins can have an impact).

As you can see, the Java sensor is in the PRE phase, so first thing is that you should be in the same phase. This explain the need for @Phase(name = Phase.Name.PRE)

Then inside the PRE phase, you want to tell SonarQube to run your Sensor before the JavaSquidSensor. This can be achieved using @DependsUpon("squid").

Basically, SonarQube will sort Sensors, using the rule @DependsUpon("xxx") < @DependedUpon("xxx")

Note that all this is only possible because JavaSquidSensor is annotated with @DependedUpon("squid"), probably for backward compatibility. You don’t really explain your use case, but I would not count too much on the stability of this on the long run. Can you elaborate a bit on what you mean by

to do some pre-scan configurations

4

Hi @Julien_HENRY,

Thank you very much for the explanation and guide!

Following your instruction, I managed to have it work now with below annotations:

@Phase(name = Phase.Name.PRE)
@DependedUpon("BEFORE_SQUID")

However still I have some uncertains:

  1. where can I find the possible values list for @DependedUpon?
    e.g. if I have two custom sensors CS1 and CS2, and I want CS2 runs before CS1, how can I tell Sonar that?

  2. regarding your saying " Note that all this is only possible because JavaSquidSensor is annotated with @DependedUpon("squid") , probably for backward compatibility. You don’t really explain your use case, but I would not count too much on the stability of this on the long run", this is also concerns me now, let me explain my use case please:

  • I need to pass some runtime configs to sonar scanner, this we do like -Dreport.dir=… -Dproject.name=…
  • our custom rule check will need to be able to read these config values before scan really starts
  • since we can only have SonarJava plugin does our rule scan within JavaSquidSensor, we have to pass the runtime config values before JavaSquidSensor
  • so we created our own sensor to handle these config values and pass to our rules.
    these are what i mean the pre-scan configurations.
    what would you suggest please if I have made my use case clear?

Thanks a lot a lot!

5

The value used used by the annotation can be any String. So to order 2 sensors you have to have them agree on a common value.

Pre-configuring the project before the analysis would be better handled by using the ProjectBuilder extension point. This extension point runs very early, before Sensors.
You will see it is marked as deprecated, since it allows to do far too many things, and we may some day drop it and replace it with one or multiple more limited extension point(s). But if your use case is simply to pre-configure some properties, I think you are safe. IMO it is more future-proof than depending on Sensor ordering.

6

Hi @Julien_HENRY,

Great, I see ProjectBuilder now, looks like we can extend it and do our configure in the build method. Oh sorry I forgot one thing, my configuration also needs to read the InputFiles that scanner has indexed with exclusion filtered out, we need to do some check against each file. With Sensor I get them using below: is this also possible with ProjectBuilder please?

        FilePredicates predicates = sensorContext.fileSystem().predicates();
        Iterable<InputFile> inputFiles = sensorContext.fileSystem().inputFiles(
                predicates.all());

So to order 2 sensors you have to have them agree on a common value.

could you also kindly guide how we do the agreement please?

7

ProjectBuilder can’t access the filesystem. Since you can change any property, including those that can influence how input files are listed/classified, that would cause a lifecycle issue.

Simply choose a common String constant.

If you want to understand deeply how it works, I suggest you have a look at the code:

8

Hi @Julien_HENRY,

Thank you very much, I will look into the source code and try to understand the sorting mechanism, very appreciated your help~

9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.