Allow using specific credentials for Checks

[meiswjn]

What feature do you want to see added?

Currently, the Checks API uses the GitHub App credentials used to check out the code. We tested the GitHub Checks Plugin with one of our template pipelines (some linters, warningsNg, test coverage, etc.) and it consumed between 50-100 requests from the rate limit. Our rate limit is 15.000 / hour, so we could build ~150 builds per hour of this kind. We provide a Jenkins instance for lots of users and rate limits are a serious issue. If the checks failed because the rate limit breaches, it wouldn't be such a big issue, but if the checks cause our rate limits to breach and as a result not even the checkouts work anymore, we definetly have an issue. This could be solved by giving the possibility to define extra credentials for the checks plugin. This would decouple the rate limit of the checks from the more critical rate limit of checking out code.

This would also allow users to solve a security issue: If the App is no longer used to checkout code, it does no longer need permissions to the repository contents and could be reduced to having access to the Checks. In GitHub Enterprise, a GitHub App cannot be created by the user themself. We have to set it up and he can then add their own repository to it (limited to 100 repositories). This of course also grants all other users of the app access to his repository.

With the new feature, the user could use their own personal access token to checkout the code and use the GitHub App only for the checks.

Thanks for this plugin - it is very useful!

Upstream changes

No response

[KalleOlaviNiemitalo]

If this were implemented, then it could be possible to specify the credentials ID in the withChecks and publishChecks pipeline steps, but I don't think those could control which credentials Jenkins uses for "status checks". That would instead have to be set in the configuration of the project, perhaps as part of GitHubSCMSourceChecksTrait.

[timja]

You can tune what it does by e.g. disabling Suppress progress updates in job check

That would likely reduce your rate limiting chance.

Or creating multiple GitHub org folders each with it's own GitHub app to get 15000 api calls per folder

[meiswjn]

You can tune what it does by e.g. disabling Suppress progress updates in job check

That would likely reduce your rate limiting chance.

Yes, with that option it goes down from 100 requests to 50.

Or creating multiple GitHub org folders each with it's own GitHub app to get 15000 api calls per folder

We do not use GitHub Org folders. We use normal Multibranch pipelines in combination with the GitHub Branch Source plugin. This would also bring high maintenance efforts on our administration site if we had to create an app for every team.

By the way, a user just wrote me a few minutes ago that they noticed that the Checks plugin used 1500 API calls from their app within 5 minutes.. maybe batching API calls is an option? Not sure if thats possible with the GitHub API.

[timja]

Roughly it should be doing:

• Queued
• Inprogress
• Completed

Along with

• Completed

For each plugin you are using that is integrated with checks

By the way, a user just wrote me a few minutes ago that they noticed that the Checks plugin used 1500 API calls from their app within 5 minutes.. maybe batching API calls is an option? Not sure if thats possible with the GitHub API.

Unlikely but not useful without knowing what calls were done or more details

[meiswjn]

Roughly it should be doing:

• Queued
• Inprogress
• Completed

Along with

• Completed

For each plugin you are using that is integrated with checks

By the way, a user just wrote me a few minutes ago that they noticed that the Checks plugin used 1500 API calls from their app within 5 minutes.. maybe batching API calls is an option? Not sure if thats possible with the GitHub API.

Unlikely but not useful without knowing what calls were done or more details

I think you are right. Probably mixed this up with the pipeline scan, as it scans every time after the new config is applied. I guess that made many API calls. I tested it again. I made two runs, one with updating checks regularly (91 calls) and one without (37 calls), so disabling the updated checks certainly helps.

I guess we would need an option to enforce this for all users, especially since it is enabled by default.