Repo ownership config is not detected when the artifact name and the repo name diverged

[balakine]

Noticed on tikal-multijob-plugin after the artifact was renamed to jenkins-multijob-plugin, but the repo itself and the developers team name remained tikal-multijob-plugin.

[alecharp]

I don't think this is a bug in Plugin Health Scoring. This is the normal behaviour. We expect to see the plugin artifactId used in the team name.

The plugin has some misconfigurations:

• https://github.com/jenkinsci/jenkins-multijob-plugin/blob/master/pom.xml#L13
• https://github.com/jenkinsci/jenkins-multijob-plugin/blob/master/pom.xml#L42-L44
• https://github.com/jenkinsci/jenkins-multijob-plugin/blob/master/.github/CODEOWNERS (even GitHub complains about its content)

All those points to the "old" name.

[balakine]

Thank you for pointing out the old names. The repo and the team have been renamed over the weekend to match the artifact name, which was changed years ago. I should have probably mentioned this conversation that lead to me opening this issue.

[timja]

Repository names and team names can evolve over time without the artifact id changing.

An example would be ssh-slaves where it is rebranded with agents in the name, the repository is renamed and likely the team as well

[alecharp]

So you would argue that the team should be composed of the repository name not of the artifactId @timja? That I can understand and we can tweak the code for it.

We need to change https://github.com/jenkins-infra/plugin-health-scoring/blob/1c950c801e5bce7f6a2941862431d6f9840424e0/core/src/main/java/io/jenkins/pluginhealth/scoring/probes/CodeOwnershipProbe.java#L63 to use context.getRepositoryName() (with some other management as the method returns a Optional<String> but that's feasible.

However, I don't know when I'll be able to work on this.

[timja]

I think repository name would be more accurate yeah.