-
Improvement
-
Resolution: Fixed
-
Minor
The current API in scm-api allows to re-index a branch source using the method SCMSourceOwner.onSCMSourceUpdated().
Currently we are using this method to force a reindexing when a webhook event is received:
for (final SCMSourceOwner owner : SCMSourceOwners.all()) { for (SCMSource source : owner.getSCMSources()) { if (source instanceof GitHubSCMSource) { GitHubSCMSource gitHubSCMSource = (GitHubSCMSource) source; if (gitHubSCMSource.getRepoOwner().equals(changedRepository.getUserName()) && gitHubSCMSource.getRepository().equals(changedRepository.getRepositoryName())) { owner.onSCMSourceUpdated(gitHubSCMSource); } } } }
We need to improve this because when Jenkins receives an event from a webhook we want to be able to determinate:
- if we have to re-index my GitHub Organization
- if we have to re-index all my branches and pull requests in a GitHub repository
- Or simplify if we have to schedule a build because there is a new commit in a pull requests
- is related to
-
JENKINS-34727 WebHook events are not always successfully triggering Jenkins pipeline
-
- Resolved
-
-
-
- Closed
-
[JENKINS-34600] Improve the performance of scheduling a build
Or webhooks have to support both auth and non auth mode (and in the case of non auth, then you can't trust and have to fetch).
Fixed in the SCM-API 2.0.x line with the fine-grained event system
As noted in
JENKINS-34727, a naïve implementation would be vulnerable to a (low-severity) exploit whereby an anonymous agent sends a crafted webhook convincing Jenkins to build a commit which is not in fact the head of the branch.Basically, if you want to bypass going back to the server to ask for the head commit, you must accept only authenticated webhooks.
Alternately, you can continue to ask the server for the head commit, but only for this one branch, which would still be safe in the face of an anonymous webhook but might be more efficient than the current behavior (TBD).