search

jenkins-infra / crawler

tools crawler
26 stars 65 forks source link

Update crawler to list scanner for msbuild netcore #75

Closed Evangelink closed 6 years ago

Evangelink commented 6 years ago

Hi,

Sorry for this missed 1st PR.

We are currently working on our Jenkins plugin to provide the ability for our end-users to user the .net core version of one of our product (scanner for msbuild). As part of this change we needed to update the crawler so that the users can select the scanner for .net core in the drop-down of the plugin configuration.

I put a [do not merge] in the title because we would like to be able to synchronize the release of our plugin with the availability of the new scanners in the drop-down to avoid (reduce is more appropriate) the number of support request we would/could receive from users.

Cheers, Amaury

daniel-beck commented 6 years ago

[do not merge]

This PR seems to lack an explanation/motivation.

Evangelink commented 6 years ago

Hi again,

ITs for our jenkins plugin actually relies on this crawler so we would be grateful if you could actually approve/merge this PR when you can.

I do hope the explanations on my first message are clear enough for you to understand the motivation behind those changes?

Thanks!

Evangelink commented 6 years ago

@daniel-beck you are probably quite busy but is there anything I need to do/improve on this PR? I would greatly appreciate if you could have a look at it in the near future so that we can release our product.

Thanks!

daniel-beck commented 6 years ago

I cannot promise an ETA for this. We generally have very little staffing for Jenkins project infrastructure.

Evangelink commented 6 years ago

I can understand. Hope you will have some time.

henryju commented 6 years ago

Hi @daniel-beck what do you think of the approach used in https://github.com/jenkins-infra/crawler/blob/master/sbuild.groovy where they kind of replaced the crawler logic by simply maintaining a dedicated static property file in an external location? I feel it is kind of defeating the purpose of getting list of installable tools from trusted locations, but well, if you are understaffed, it would allow us to be more autonomous. Would you agree if we were moving to the same strategy?

daniel-beck commented 6 years ago

@henryju Thanks for the ping. My GitHub use this week is mostly notification driven, sorry about that. FWIW filing an infra issue in our Jira might have taken care of this more quickly. Random PRs tend to not get a lot of attention. Perhaps try https://issues.jenkins-ci.org/browse/INFRA in the future.

I've been able to run the updated script, and it only changes labels and adds "netcore" entries. Their labels aren't exactly user friendly IMO but perhaps that's a deliberate choice.

I'm +1 on this PR. Given the original PR message I will not merge without coordinating the time with you.

Regarding your proposal: Not sure what the best way to do that would be. Notably, today, people can just file issues with the Jenkins project when the metadata is broken/outdated, and we can investigate. Being the middle man between users and you without ability to fix things would not be great. It should be obvious how to handle this in the future.

henryju commented 6 years ago

@daniel-beck Can you merge please?

daniel-beck commented 6 years ago

@henryju @Evangelink Done.

henryju commented 6 years ago

Thanks!