Code maintainance scoring implementation

[alecharp]

Description

In the project, we now have a few probes which can provide useful details about the quality of the code and its maintainability:

• Spotbugs
• Code Coverage
• Jenkins core version

The idea would be to have a separate scoring implementation from the PluginMaintenanceScoring, which would evaluate the code of the plugin.
Other probes could be added in the future (not part of this task) to complement this new scoring implementation.

Requirements

• Key: code-maintainability
• Coefficient: .8
• Uses probes
  • Spotbugs needs to be configured
  • Spotbugs shouldn't report any issue (40% of the score)
  • Code coverage needs to be configured
  • Code coverage should report at least 70% of line covered (40% of the score)
  • Jenkins core requirement should be a LTS (10% of the score)
  • Jenkins core requirement should be not older than 3 LTS version back (see https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline (10% of the score)

[jleon33]

I like the idea of this. One concern I have is it sounds vaguely similar to repository configurations.

[alecharp]

I like the idea of this. One concern I have is it sounds vaguely similar to repository configurations.

it would be yes. But with a different concern in mind: what is the "quality" of the plugin code, which is used.
The repository configuration is about what is put in place to ease the maintainer job.

Those are not completely separate but more complementary in my mind.

[jleon33]

As long as its clear to a user what the difference is, I think this is a great idea

[AayushSaini101]

Adding more points in this scoring implementation as it to analyse the quality of the plugin:

• Spotless configured or not
• Junit4 is used or not

[AayushSaini101]

@alecharp I am on it

[alecharp]

Please make sure to finish what you already started.

[AayushSaini101]

Please make sure to finish what you already started.
@alecharp I have proposed ideas for GSOC in this issue. Please add gsoc label

[alecharp]

No I won't and let me explain why. This issue was created in the context of GSoC, yes, but last year (2023). I was created by me, after observation with Jagruti that we were creating new probes but weren't using them. That is in fact a common problem on this project.
But, this is not something you can call dibs on. Nor you can on anything opensource for that matter.
More over, you cannot claim ownership on something that is not yours.

So, you may include the implementation of this issue in your GSoC proposal, but I encourage you to understand that if anyone, new or not to this project, wants to contribute this implementation, they can and they are welcome to. Because it is for the benefit of the project, not to one individual.

[AayushSaini101]

No I won't and let me explain why. This issue was created in the context of GSoC, yes, but last year (2023). I was created by me, after observation with Jagruti that we were creating new probes but weren't using them. That is in fact a common problem on this project. But, this is not something you can call dibs on. Nor you can on anything opensource for that matter. More over, you cannot claim ownership on something that is not yours.

So, you may include the implementation of this issue in your GSoC proposal, but I encourage you to understand that if anyone, new or not to this project, wants to contribute this implementation, they can and they are welcome to. Because it is for the benefit of the project, not to one individual.

Thanks @alecharp for your suggestions. I have proposed the fix in my proposal along with additional probes modified as security analysis of plugin :)