Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70772

Multi-branch scan is no more triggered by webhook after update

      Multi-branch scan is no more triggered by webhook after update to Jenkins 2.375.2 and latest plugin-versions at that time.

      Before the update: when a new branch was pushed to BitBucket, the scan was triggered immediately and automatically. Now the developers are puzzled why their new banch is not found in Jenkins after they pushed. As a workaround, we configured the poll to minimal value of 1 min, but it's still a nuisance for the developers.

      We are using the generic webhook in BitBucket and it's pointed to the "git/notifyCommit"-endpoint in jenkins. The webhook is otherwise working: the jobs that we have allowed to do "automatic SCM triggering" are getting automatically built.

      Because of the update, we had to add the token to the webhook url, because of the some security fix in Jenkins. We are suspecting whether the token-related changes in Jenkins/plugins broke the automatic rescan ( a long shot from us, yes, sorry for that).

      While troubleshooting and searching if this is a known defect, we found out about "Multibranch Scan Webhook Trigger"-plugin. We have never had that installed, and never knew about it -because the scan was already automatically triggered by the webhook. if that's the way to go, then we'll walk it. But, there seems to be some regression, because earlier the scan was working without additional plugins. Also picked Major as it seems like a regression in LTS, but I'm not sure about the Jenkins project conventions.

      I really don't know which component provides the functionality. I had to choose one, so I picked "pipeline". That could be wrong, of course.

          [JENKINS-70772] Multi-branch scan is no more triggered by webhook after update

          Kari Niemi added a comment -

          Also, in "MultiBranch Pipeline Triggers", the help of "Periodically it not otherwise run" states:
          Some kinds of folders are reindexed automatically and immediately upon receipt of an external event. For example, a multi-branch project will recheck its SCM repository for new or removed or modified branches when it receives an SCM change notification. (Push notification may be configured as per the SCM plugin used for each respective branch source.) Such notifications can occasionally be unreliable, however, or Jenkins might not even be running to receive them. In some cases no immediate notification is even possible, for example because Jenkins is behind a firewall and can only poll an external system.

          This trigger allows for a periodic fallback, but when necessary. If no indexing has been performed in the specified interval, then an indexing will be scheduled. For example, in the case of a multi-branch project, if the source control system is not configured for push notification, set a short interval (most people will pick between 15 minutes and 1 hour). If the source control system is configured for push notification, set an interval that corresponds to the maximum acceptable delay in the event of a lost push notification as the last commit of the day. (Subsequent commits should trigger indexing anyway and result in the commit being picked up, so most people will pick between 4 hours and 1 day.)

          So it would seem that the webhook triggered rescan should be working without additional plug-ins?

          Kari Niemi added a comment - Also, in "MultiBranch Pipeline Triggers", the help of "Periodically it not otherwise run" states: Some kinds of folders are reindexed automatically and immediately upon receipt of an external event. For example, a multi-branch project will recheck its SCM repository for new or removed or modified branches when it receives an SCM change notification. (Push notification may be configured as per the SCM plugin used for each respective branch source.) Such notifications can occasionally be unreliable, however, or Jenkins might not even be running to receive them. In some cases no immediate notification is even possible, for example because Jenkins is behind a firewall and can only poll an external system. This trigger allows for a periodic fallback, but when necessary. If no indexing has been performed in the specified interval, then an indexing will be scheduled. For example, in the case of a multi-branch project, if the source control system is not configured for push notification, set a short interval (most people will pick between 15 minutes and 1 hour). If the source control system is configured for push notification, set an interval that corresponds to the maximum acceptable delay in the event of a lost push notification as the last commit of the day. (Subsequent commits should trigger indexing anyway and result in the commit being picked up, so most people will pick between 4 hours and 1 day.) So it would seem that the webhook triggered rescan should be working without additional plug-ins?

          Kari Niemi added a comment -

          It seems our hunch was correct, the problem is related to the new token parameter... but actually the bug is in our side :

          # curl -k -X  POST "http://localhost:8080/git/notifyCommit?url=https://xxx/bitbucket/scm/yyy/zzz.git?&token=abcdabcdacbdabcd"
          No git jobs using repository: https://xxx/bitbucket/scm/yyy/zzz.git? and branches: 
          No Git consumers using SCM API plugin for: https://xxx/bitbucket/scm/yyy/zzz.git?
          

          Note the "?" at the end of the responses. Unfortunately, our ICT guys had added the new token parameter incorrectly in the webhook-tigger: they used "?&" as the separator for url-parameters instead of the correct "&".

          Kari Niemi added a comment - It seems our hunch was correct, the problem is related to the new token parameter... but actually the bug is in our side : # curl -k -X  POST "http: //localhost:8080/git/notifyCommit?url=https://xxx/bitbucket/scm/yyy/zzz.git?&token=abcdabcdacbdabcd" No git jobs using repository: https: //xxx/bitbucket/scm/yyy/zzz.git? and branches:  No Git consumers using SCM API plugin for : https: //xxx/bitbucket/scm/yyy/zzz.git? #  Note the "?" at the end of the responses. Unfortunately, our ICT guys had added the new token parameter incorrectly in the webhook-tigger: they used "?&" as the separator for url-parameters instead of the correct "&".

          Kari Niemi added a comment -

          So, this is a OSI layer 8 problem, that is a user error. Please close the ticket as invalid!

          Kari Niemi added a comment - So, this is a OSI layer 8 problem, that is a user error. Please close the ticket as invalid!

            Unassigned Unassigned
            karniemi Kari Niemi
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: