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

Pipeline: GitHub webhook received but nothing happens

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: github-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.3
      Github Plugin 1.19.1
      Git Plugin 2.4.4
    • Similar Issues:

      Description

      I apologize if this is something known that I've overlooked.

      I've created a small pipeline project in Jenkins to manage Github pushes against some of my enabled repositories. These jobs were brand new, typed as Pipeline jobs (not multibranch - I haven't got the buy-in from my developers to add Jenkinsfiles yet). I have Jenkins configured to automatically create webhooks against these projects, which works perfectly. I am also able to manually run jobs, whereupon I can pull the code and the pipeline builds out as intended.

      The problem lies in Jenkins kicking off the build when the POST is received. For all of these repositories, watching the Jenkins logs, I see this:

      May 25, 2016 4:09:45 PM org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent
      INFO: Received POST for https://github.com/[org]/[repo]
      

      But afterwards, nothing happens: no build starts, no exceptions are triggered, nothing. I've read through the plugin and thought this might be a mismatched class type for the job, but I am not a pro at Java, much less Jenkins plugin syntax.

      Am I missing something here? Is there lacking support for this version?

      VERY much appreciate any help anyone can provide. I've been tearing my hair out about this for a few days.

        Attachments

        1. github-polling-log.png
          github-polling-log.png
          11 kB
        2. screenshot-1.png
          screenshot-1.png
          29 kB
        3. screenshot-2.png
          screenshot-2.png
          123 kB

          Activity

          Hide
          lanwen Kirill Merkushev added a comment -

          Please provide your job config with trigger and scm section
          Also please enable logs as mentioned on plugin wiki and post them here after hook will be received.

          Show
          lanwen Kirill Merkushev added a comment - Please provide your job config with trigger and scm section Also please enable logs as mentioned on plugin wiki and post them here after hook will be received.
          Hide
          jachandler Josh Chandler added a comment -

          Thanks for your response!

          I have attached a partially-redacted view of the config for the first job that gave me this issue. Particularly, I have redacted my organization name (by request of my superiors). Suffice it to say that when I do manually kick this off, it is able to reach git to pull code without an issue. The hook was installed successfully and I do receive it on my Jenkins.

          Here is the config for this job:

          <?xml version='1.0' encoding='UTF-8'?>
          <flow-definition plugin="workflow-job@2.1">
            <actions/>
            <description></description>
            <keepDependencies>false</keepDependencies>
            <properties>
              <com.coravy.hudson.plugins.github.GithubProjectProperty plugin="github@1.19.1">
                <projectUrl>https://github.com/org/toy-box.git/</projectUrl>
                <displayName></displayName>
              </com.coravy.hudson.plugins.github.GithubProjectProperty>
            </properties>
            <definition class="org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition" plugin="workflow-cps@2.2">
              <script>// Define all required variables. Most will be disseminated to the environment.
          def projectName=&apos;toy-box&apos;
          def tagName = &quot;1.1-&quot; + new Date().format(&apos;yyyyMMdd&apos;) + &apos;.&apos; + env.BUILD_NUMBER
          def imageName = &quot;[REDACTED]&quot;
          def clusterToken=&quot;[REDACTED]&quot;
          def slack = [channel: &apos;[REDACTED]&apos;, teamDomain: &apos;[REDACTED]&apos;, token: &apos;[REDACTED]&apos;]
          def logPath = &quot;/var/jenkins_home/jobs/${env.JOB_NAME}/builds/${env.BUILD_NUMBER}/log&quot;
          def deploymentResponders = &quot;Could you please have a look?&quot;
          
          node {
              try {
                  stage &apos;Checkout Code&apos;
                      git credentialsId: &apos;[REDACTED]&apos;, poll: false, url: &apos;https://github.com/org/toy-box.git&apos;
                  stage &apos;Build Project&apos;
                      def npmLocation = tool name: &apos;node_5.10.0&apos;, type: &apos;jenkins.plugins.nodejs.tools.NodeJSInstallation&apos;
                      sh &quot;${npmLocation}/bin/npm install&quot;
                  stage &apos;Automated Test&apos;
                      echo &apos;No tests defined for this project.&apos;
                  stage &apos;Build Docker Image&apos;
                      sh &quot;docker-build.sh --image ${imageName}&quot;
                      slackSend channel: slack.channel, color: &apos;good&apos;, message: &quot;Docker image build success for build #${env.BUILD_NUMBER} of ${projectName}!&quot;, teamDomain: slack.teamDomain, token: slack.token
                  stage &apos;QA Deployment&apos;
                      echo &apos;QA Deploy is being skipped at the moment. Please contact an administrator for more details.&apos;
                  stage &apos;QA Testing Begins&apos;
                      echo &apos;QA Test is being skipped at the moment. Please contact an administrator for more details.&apos;
                  stage &apos;QA Testing Passed&apos;
                      echo &apos;QA Test is being skipped at the moment. Please contact an administrator for more details.&apos;
                  stage &apos;Production Deployment&apos;
                      slackSend channel: slack.channel, color: &apos;good&apos;, message: &quot;Awaiting deployment approval for build #${env.BUILD_NUMBER} of ${projectName}. &quot; + deploymentResponders, teamDomain: slack.teamDomain, token: slack.token
                      input message: &apos;Ready to roll out?&apos;, ok: &apos;Go!&apos;
                      sh &quot;cloud-deployment.sh --image ${imageName} --deployment ${projectName} --token ${clusterToken}&quot;
                      slackSend channel: slack.channel, color: &apos;good&apos;, message: &quot;Production deploy success for build #${env.BUILD_NUMBER} of ${projectName}!&quot;, teamDomain: slack.teamDomain, token: slack.token
              } catch (org.jenkinsci.plugins.workflow.steps.FlowInterruptedException fx) {
                  slackSend channel: slack.channel, color: &apos;red&apos;, message: &quot;Build ${projectName}:#${env.BUILD_NUMBER} aborted.&quot;, teamDomain: slack.teamDomain, token: slack.token
              } catch (err) {
                  slackSend channel: slack.channel, color: &apos;bad&apos;, message: &quot;Build failure! See ${projectName} #${env.BUILD_NUMBER} logs for more details.&quot;, teamDomain: slack.teamDomain, token: slack.token
                  throw err
              } finally {
                  echo &quot;Log shipping disabled until we deal with the gsutil issue...&quot;
                  //sh &quot;log-to-buckets.sh --path ${logPath} --name ${projectName} --build-number ${env.BUILD_NUMBER}&quot;
              }
          }</script>
              <sandbox>true</sandbox>
            </definition>
            <triggers>
              <com.cloudbees.jenkins.GitHubPushTrigger plugin="github@1.19.1">
                <spec></spec>
              </com.cloudbees.jenkins.GitHubPushTrigger>
            </triggers>
          

          I have also tried "poll: true" on the git portion, but that doesn't make any difference - I didn't really expect it to since none of these steps are being reached.

          This is all that happens after the hook is received:

          May 25, 2016 6:39:19 PM org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent
          INFO: Received POST for https://github.com/org/toy-box
          

          Unfortunately, this is all it produced. I can disable/re-enable the hook installation if you'd like, but since I am receiving a payload I don't think the issue is there. Could it possibly be something to do with the job type not being interpretable by the plugin?

          Show
          jachandler Josh Chandler added a comment - Thanks for your response! I have attached a partially-redacted view of the config for the first job that gave me this issue. Particularly, I have redacted my organization name (by request of my superiors). Suffice it to say that when I do manually kick this off, it is able to reach git to pull code without an issue. The hook was installed successfully and I do receive it on my Jenkins. Here is the config for this job: <?xml version= '1.0' encoding= 'UTF-8' ?> <flow-definition plugin= "workflow-job@2.1" > <actions/> <description> </description> <keepDependencies> false </keepDependencies> <properties> <com.coravy.hudson.plugins.github.GithubProjectProperty plugin= "github@1.19.1" > <projectUrl> https://github.com/org/toy-box.git/ </projectUrl> <displayName> </displayName> </com.coravy.hudson.plugins.github.GithubProjectProperty> </properties> <definition class= "org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition" plugin= "workflow-cps@2.2" > <script> // Define all required variables. Most will be disseminated to the environment. def projectName=&apos;toy-box&apos; def tagName = &quot;1.1-&quot; + new Date().format(&apos;yyyyMMdd&apos;) + &apos;.&apos; + env.BUILD_NUMBER def imageName = &quot;[REDACTED]&quot; def clusterToken=&quot;[REDACTED]&quot; def slack = [channel: &apos;[REDACTED]&apos;, teamDomain: &apos;[REDACTED]&apos;, token: &apos;[REDACTED]&apos;] def logPath = &quot;/var/jenkins_home/jobs/${env.JOB_NAME}/builds/${env.BUILD_NUMBER}/log&quot; def deploymentResponders = &quot;Could you please have a look?&quot; node { try { stage &apos;Checkout Code&apos; git credentialsId: &apos;[REDACTED]&apos;, poll: false, url: &apos;https://github.com/org/toy-box.git&apos; stage &apos;Build Project&apos; def npmLocation = tool name: &apos;node_5.10.0&apos;, type: &apos;jenkins.plugins.nodejs.tools.NodeJSInstallation&apos; sh &quot;${npmLocation}/bin/npm install&quot; stage &apos;Automated Test&apos; echo &apos;No tests defined for this project.&apos; stage &apos;Build Docker Image&apos; sh &quot;docker-build.sh --image ${imageName}&quot; slackSend channel: slack.channel, color: &apos;good&apos;, message: &quot;Docker image build success for build #${env.BUILD_NUMBER} of ${projectName}!&quot;, teamDomain: slack.teamDomain, token: slack.token stage &apos;QA Deployment&apos; echo &apos;QA Deploy is being skipped at the moment. Please contact an administrator for more details.&apos; stage &apos;QA Testing Begins&apos; echo &apos;QA Test is being skipped at the moment. Please contact an administrator for more details.&apos; stage &apos;QA Testing Passed&apos; echo &apos;QA Test is being skipped at the moment. Please contact an administrator for more details.&apos; stage &apos;Production Deployment&apos; slackSend channel: slack.channel, color: &apos;good&apos;, message: &quot;Awaiting deployment approval for build #${env.BUILD_NUMBER} of ${projectName}. &quot; + deploymentResponders, teamDomain: slack.teamDomain, token: slack.token input message: &apos;Ready to roll out?&apos;, ok: &apos;Go!&apos; sh &quot;cloud-deployment.sh --image ${imageName} --deployment ${projectName} --token ${clusterToken}&quot; slackSend channel: slack.channel, color: &apos;good&apos;, message: &quot;Production deploy success for build #${env.BUILD_NUMBER} of ${projectName}!&quot;, teamDomain: slack.teamDomain, token: slack.token } catch (org.jenkinsci.plugins.workflow.steps.FlowInterruptedException fx) { slackSend channel: slack.channel, color: &apos;red&apos;, message: &quot;Build ${projectName}:#${env.BUILD_NUMBER} aborted.&quot;, teamDomain: slack.teamDomain, token: slack.token } catch (err) { slackSend channel: slack.channel, color: &apos;bad&apos;, message: &quot;Build failure! See ${projectName} #${env.BUILD_NUMBER} logs for more details.&quot;, teamDomain: slack.teamDomain, token: slack.token throw err } finally { echo &quot;Log shipping disabled until we deal with the gsutil issue...&quot; //sh &quot;log-to-buckets.sh --path ${logPath} --name ${projectName} --build-number ${env.BUILD_NUMBER}&quot; } } </script> <sandbox> true </sandbox> </definition> <triggers> <com.cloudbees.jenkins.GitHubPushTrigger plugin= "github@1.19.1" > <spec> </spec> </com.cloudbees.jenkins.GitHubPushTrigger> </triggers> I have also tried "poll: true" on the git portion, but that doesn't make any difference - I didn't really expect it to since none of these steps are being reached. This is all that happens after the hook is received: May 25, 2016 6:39:19 PM org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent INFO: Received POST for https://github.com/org/toy-box Unfortunately, this is all it produced. I can disable/re-enable the hook installation if you'd like, but since I am receiving a payload I don't think the issue is there. Could it possibly be something to do with the job type not being interpretable by the plugin?
          Hide
          whughes Will Hughes added a comment - - edited

          I am having the same problem

          Edit: And I can also confirm that if I make a freestyle project with the same repo and trigger the webhook, Jenkins recognises this and starts the build (only for the freestyle project)

          Show
          whughes Will Hughes added a comment - - edited I am having the same problem Edit: And I can also confirm that if I make a freestyle project with the same repo and trigger the webhook, Jenkins recognises this and starts the build (only for the freestyle project)
          Hide
          lanwen Kirill Merkushev added a comment -

          What is in github-polling log?

          Show
          lanwen Kirill Merkushev added a comment - What is in github-polling log?
          Hide
          jachandler Josh Chandler added a comment -

          Show
          jachandler Josh Chandler added a comment -
          Hide
          jachandler Josh Chandler added a comment -

          I remember seeing in the plugin code where polling could possibly be run, but it simply never reaches that block. Thinking these workflow job type objects don't fit the inheritance hierarchy expected to kick off a build, so the code after the hook is received never fires.

          Show
          jachandler Josh Chandler added a comment - I remember seeing in the plugin code where polling could possibly be run, but it simply never reaches that block. Thinking these workflow job type objects don't fit the inheritance hierarchy expected to kick off a build, so the code after the hook is received never fires.
          Hide
          lanwen Kirill Merkushev added a comment -

          You should build wf job manually first time to initialize git-scm info. Did you try to build it without hook?

          Show
          lanwen Kirill Merkushev added a comment - You should build wf job manually first time to initialize git-scm info. Did you try to build it without hook?
          Hide
          jachandler Josh Chandler added a comment -

          I believe I have, yes - I am implementing the full pipeline as in the script I originally posted, and then hitting "Build Now". I was going to install webhooks to finish out the project when I encountered the issue. The pipeline itself runs without a hitch. I am using this code to do this:

          stage 'Checkout Code'
          git credentialsId: 'my-credential-id', poll: false, url: 'https://github.com/my-org/my-repository.git'

          Setting poll: true makes no difference - I attempted a build just now with the flag set to true: the build was successful to the end, but the logs still read "Polling has not run yet."

          Is there some different incantation I should be using during the 'Checkout Code' phase that will accomplish this? Am I supposed to run an individual phase somehow instead of the entire pipeline? Is there some way I can force git-scm to initialize?

          Show
          jachandler Josh Chandler added a comment - I believe I have, yes - I am implementing the full pipeline as in the script I originally posted, and then hitting "Build Now". I was going to install webhooks to finish out the project when I encountered the issue. The pipeline itself runs without a hitch. I am using this code to do this: stage 'Checkout Code' git credentialsId: 'my-credential-id', poll: false, url: 'https://github.com/my-org/my-repository.git' Setting poll: true makes no difference - I attempted a build just now with the flag set to true: the build was successful to the end, but the logs still read "Polling has not run yet." Is there some different incantation I should be using during the 'Checkout Code' phase that will accomplish this? Am I supposed to run an individual phase somehow instead of the entire pipeline? Is there some way I can force git-scm to initialize?
          Hide
          _cp CP N added a comment -

          I am facing the same issue as well on Jenkins 2.8. There is no exception or errors logged in the webhook logs in Jenkins (followed the steps on plugin page). In my case, I using the GITHUB Organization Folder and corresponding organization hook in GITHUB. The POST is reaching fine to Jenkins, but the build do not get started.

          Is it because, there is build trigger related to build when a commit happens is missing in Jenkins 2.x New Job?

          Show
          _cp CP N added a comment - I am facing the same issue as well on Jenkins 2.8. There is no exception or errors logged in the webhook logs in Jenkins (followed the steps on plugin page). In my case, I using the GITHUB Organization Folder and corresponding organization hook in GITHUB. The POST is reaching fine to Jenkins, but the build do not get started. Is it because, there is build trigger related to build when a commit happens is missing in Jenkins 2.x New Job?
          Hide
          wallnerryan Ryan Wallner added a comment -

          +1 i am facing the same issue on 2.7.2

          Show
          wallnerryan Ryan Wallner added a comment - +1 i am facing the same issue on 2.7.2
          Hide
          lanwen Kirill Merkushev added a comment -

          GH Organization Folder is not a Github-plugin

          Show
          lanwen Kirill Merkushev added a comment - GH Organization Folder is not a Github-plugin
          Hide
          misko Michal Medvecky added a comment -

          +1, Jenkins 2.21, GH org plugin 1.4

          very unhappy about this

          Show
          misko Michal Medvecky added a comment - +1, Jenkins 2.21, GH org plugin 1.4 very unhappy about this
          Hide
          chadmyers Chad Myers added a comment -

          +1 Jenkins 2.15, Jenkins-github plugin 1.19.2, no GH org folder plugin

          I see the webhook hit in the logs, but it doesn't trigger my Pipeline build.

          I noticed that Pipeline builds in Jenkins don't have an SCM section. Is that the cause for this problem?

          Show
          chadmyers Chad Myers added a comment - +1 Jenkins 2.15, Jenkins-github plugin 1.19.2, no GH org folder plugin I see the webhook hit in the logs, but it doesn't trigger my Pipeline build. I noticed that Pipeline builds in Jenkins don't have an SCM section. Is that the cause for this problem?
          Hide
          chadmyers Chad Myers added a comment -

          I see this in the hook log:

          Oct 11, 2016 8:23:03 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent
          Received POST for https://github.com/

          {my org}

          /

          {my repo}

          Oct 11, 2016 8:23:03 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run
          Considering to poke

          {my pipeline build}
          Oct 11, 2016 8:23:03 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run
          Skipped {my pipeline build}

          because it doesn't have a matching repository.

          It looks like DefaultPushGHEventSubscriber calls GitHubRepositoryNameContributor.parseAssociatedNames(job). parseAssociatedNames looks through the SCMTriggers on the job and since my job is a Pipeline build, there's no SCMTrigger, and so the Github plugin skips my job.

          This seems like anyone using Jenkins 2's new Pipeline feature with Github would run into this. This seems like it should be a "Major" level issue. I'm surprised more people haven't run into this

          Show
          chadmyers Chad Myers added a comment - I see this in the hook log: Oct 11, 2016 8:23:03 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber onEvent Received POST for https://github.com/ {my org} / {my repo} Oct 11, 2016 8:23:03 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run Considering to poke {my pipeline build} Oct 11, 2016 8:23:03 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run Skipped {my pipeline build} because it doesn't have a matching repository. It looks like DefaultPushGHEventSubscriber calls GitHubRepositoryNameContributor.parseAssociatedNames(job). parseAssociatedNames looks through the SCMTriggers on the job and since my job is a Pipeline build, there's no SCMTrigger, and so the Github plugin skips my job. This seems like anyone using Jenkins 2's new Pipeline feature with Github would run into this. This seems like it should be a "Major" level issue. I'm surprised more people haven't run into this
          Hide
          bksaville Brian Saville added a comment - - edited

          Ran into the same thing here.

          UPDATE: This was due to us using the "Suppress automatic SCM triggering" option on a GitHub multibranch project. After reading through the source, I incorrectly assumed it would prevent only the initial branch index from firing off new builds, but since the GitHub plugin webhook actually uses the branch indexing to fire off builds after receiving a hook payload, it ignored those as all. Disabling this property on the multibranch project fixed the issue completely for me.

          Show
          bksaville Brian Saville added a comment - - edited Ran into the same thing here. UPDATE : This was due to us using the "Suppress automatic SCM triggering" option on a GitHub multibranch project. After reading through the source, I incorrectly assumed it would prevent only the initial branch index from firing off new builds, but since the GitHub plugin webhook actually uses the branch indexing to fire off builds after receiving a hook payload, it ignored those as all. Disabling this property on the multibranch project fixed the issue completely for me.
          Hide
          lanwen Kirill Merkushev added a comment -

          With pipeline job you should start first build manually

          Show
          lanwen Kirill Merkushev added a comment - With pipeline job you should start first build manually
          Hide
          chadmyers Chad Myers added a comment -

          Dear Kirill Merkushev,

          I have triggered the pipeline build manually the first time. I cannot get the github webhook to trigger it. The hook log says "Considering my-build" but then "Skipped my-build"

          I have also tried a Multi-branch Pipeline build and the Github webhook doesn't even say "Considering my-mb-build".

          As far as I can tell, Github Webhooks do not work at all for Pipeline and Multibranch Pipeline builds in Jenkins 2. Is this your understanding?

          Show
          chadmyers Chad Myers added a comment - Dear Kirill Merkushev , I have triggered the pipeline build manually the first time. I cannot get the github webhook to trigger it. The hook log says "Considering my-build" but then "Skipped my-build" I have also tried a Multi-branch Pipeline build and the Github webhook doesn't even say "Considering my-mb-build". As far as I can tell, Github Webhooks do not work at all for Pipeline and Multibranch Pipeline builds in Jenkins 2. Is this your understanding?
          Hide
          ancodia808 Eric Hunter added a comment -

          +1 Jenkins 2.19.1, GitHub plugin 1.22.2, GitHub Organization Folder Plugin 1.5

          Logs show:
          {{Received POST for https://github.com/<user>/<repository>
          Oct 13, 2016 8:44:58 PM FINE com.cloudbees.jenkins.GitHubRepositoryName create
          Constructing from URL https://github.com/<user>/<repository>
          Oct 13, 2016 8:44:58 PM FINE com.cloudbees.jenkins.GitHubRepositoryName create
          URL matches java.util.regex.Matcher[pattern=https?://([^/])/([^/])/([^/]+)/? region=0,44 lastmatch=https://github.com/<user>/<repository>]
          Oct 13, 2016 8:44:58 PM FINE com.cloudbees.jenkins.GitHubRepositoryName create
          Object is GitHubRepositoryName[host=github.com,username=<user>,repository=<repository>]
          Oct 13, 2016 8:44:58 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run
          Considering to poke my-pipeline
          Oct 13, 2016 8:44:58 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run
          Skipped my-pipeline because it doesn't have a matching repository.}}

          The only difference I can see is that the Jenkins UI forces a trailing "/" in the "Repository URL" entered for my Pipeline. When I review the "Repository URL" value in the pipeline config it looks like:
          https://github.com/<user>/<repository>/

          Could this be contributing to the problem?

          Temporarily using a GitHub Organization Folder, but this is not optimal as it only supports polling. Looking for an option that can be triggered off of the GitHub push event.

          Show
          ancodia808 Eric Hunter added a comment - +1 Jenkins 2.19.1, GitHub plugin 1.22.2, GitHub Organization Folder Plugin 1.5 Logs show: {{Received POST for https://github.com/ <user>/<repository> Oct 13, 2016 8:44:58 PM FINE com.cloudbees.jenkins.GitHubRepositoryName create Constructing from URL https://github.com/ <user>/<repository> Oct 13, 2016 8:44:58 PM FINE com.cloudbees.jenkins.GitHubRepositoryName create URL matches java.util.regex.Matcher[pattern=https?://( [^/] )/( [^/] )/( [^/] +)/? region=0,44 lastmatch= https://github.com/ <user>/<repository>] Oct 13, 2016 8:44:58 PM FINE com.cloudbees.jenkins.GitHubRepositoryName create Object is GitHubRepositoryName [host=github.com,username=<user>,repository=<repository>] Oct 13, 2016 8:44:58 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run Considering to poke my-pipeline Oct 13, 2016 8:44:58 PM FINE org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run Skipped my-pipeline because it doesn't have a matching repository.}} The only difference I can see is that the Jenkins UI forces a trailing "/" in the "Repository URL" entered for my Pipeline. When I review the "Repository URL" value in the pipeline config it looks like: https://github.com/ <user>/<repository>/ Could this be contributing to the problem? Temporarily using a GitHub Organization Folder, but this is not optimal as it only supports polling. Looking for an option that can be triggered off of the GitHub push event.
          Hide
          ianaz Silvio Rainoldi added a comment -

          +1.

          Same for me

          Show
          ianaz Silvio Rainoldi added a comment - +1. Same for me
          Hide
          ianaz Silvio Rainoldi added a comment -

          On the branches there's the tick (but no option to save anyways because it's auto generated)

          Why isn't the option on the main project's configuration?

          Show
          ianaz Silvio Rainoldi added a comment - On the branches there's the tick (but no option to save anyways because it's auto generated) Why isn't the option on the main project's configuration?
          Hide
          lancekuo Lance Kuo added a comment -

          +1
          Same for me.

          Show
          lancekuo Lance Kuo added a comment - +1 Same for me.
          Hide
          zeusminos Zeus Minos added a comment -

          Seams to me that I am experiencing similar issue.

          Just for reference I am using the latest Jenkins 2.35 with all the latest Gitlab/Pipeline plugins. My Gitlab (Hosted on our own servers) version is 8.13.2.
          I have been using webhooks to start other non-pipeline Jenkins jobs and it works ok. I tried to do the same thing using a pipeline Jenkins job and GitLab will return "Hook executed successfully but returned HTTP 500" and nothing happens on the Jenkins side.
          My pipeline job just display a message on the console if the job gets triggered.
          This is the link used on my Gitlab webhook: http://MyJenkinsServer/gitlab/build_now/MyPipelineJob
          Any help is more than welcome

          Down below is my pipeline code.
          http://paste.ofcode.org/B9VFa5fHxEqbxKqxLEFAki

          Show
          zeusminos Zeus Minos added a comment - Seams to me that I am experiencing similar issue. Just for reference I am using the latest Jenkins 2.35 with all the latest Gitlab/Pipeline plugins. My Gitlab (Hosted on our own servers) version is 8.13.2. I have been using webhooks to start other non-pipeline Jenkins jobs and it works ok. I tried to do the same thing using a pipeline Jenkins job and GitLab will return "Hook executed successfully but returned HTTP 500" and nothing happens on the Jenkins side. My pipeline job just display a message on the console if the job gets triggered. This is the link used on my Gitlab webhook: http://MyJenkinsServer/gitlab/build_now/MyPipelineJob Any help is more than welcome Down below is my pipeline code. http://paste.ofcode.org/B9VFa5fHxEqbxKqxLEFAki
          Hide
          integer Kanstantsin Shautsou added a comment - - edited

          Github pullrequest trigger in screenshot issues doesn't belong to github-plugin.
          You should ensure from what plugin do you use functionality, follow plugin docs and report issues according to docs.
          Github-org-folder especially offtopic for issue.
          This issue has the mess of unrelated to github-plugin questions -> Issue closed.

          Show
          integer Kanstantsin Shautsou added a comment - - edited Github pullrequest trigger in screenshot issues doesn't belong to github-plugin. You should ensure from what plugin do you use functionality, follow plugin docs and report issues according to docs. Github-org-folder especially offtopic for issue. This issue has the mess of unrelated to github-plugin questions -> Issue closed.
          Hide
          jachandler Josh Chandler added a comment - - edited

          I have a bit of a problem with this resolution. In short: I disagree entirely this is not a part of the github-plugin, with evidence from the code. Two things:

          1) It is most certainly from this plugin. The logs I captured indicate it came from this file:

          https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github/webhook/subscriber/DefaultPushGHEventSubscriber.java

          The log I posted to Kirill Merkushev indicates it came from this line:

          https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github/webhook/subscriber/DefaultPushGHEventSubscriber.java#L68

          Particularly on line 71 (for reference: https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github/webhook/subscriber/DefaultPushGHEventSubscriber.java#L71), the commentary indicates it will kick a build at this point. This is the behavior I wished to occur which did not happen.

          2) The github-plugin page at (https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin) indicates this is a primary objective of the plugin itself on the landing page:

          Trigger a job when you push to the repository by groking HTTP POSTs from post-receive hook and optionally auto-managing the hook setup.
          Report build status result back to github as Commit Status (documented on SO)

          This is exactly what I was trying to do; and this is exactly not what is happening on my server.

          If this is, after this body of evidence, somehow not related to this plugin, can you explain to us where we can collect the information required to find the right place to comment, and perhaps point us to this place?

          Show
          jachandler Josh Chandler added a comment - - edited I have a bit of a problem with this resolution. In short: I disagree entirely this is not a part of the github-plugin, with evidence from the code. Two things: 1) It is most certainly from this plugin. The logs I captured indicate it came from this file: https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github/webhook/subscriber/DefaultPushGHEventSubscriber.java The log I posted to Kirill Merkushev indicates it came from this line: https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github/webhook/subscriber/DefaultPushGHEventSubscriber.java#L68 Particularly on line 71 (for reference: https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github/webhook/subscriber/DefaultPushGHEventSubscriber.java#L71 ), the commentary indicates it will kick a build at this point. This is the behavior I wished to occur which did not happen. 2) The github-plugin page at ( https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin ) indicates this is a primary objective of the plugin itself on the landing page: Trigger a job when you push to the repository by groking HTTP POSTs from post-receive hook and optionally auto-managing the hook setup. Report build status result back to github as Commit Status (documented on SO) This is exactly what I was trying to do; and this is exactly not what is happening on my server. If this is, after this body of evidence, somehow not related to this plugin, can you explain to us where we can collect the information required to find the right place to comment, and perhaps point us to this place?
          Hide
          andreitroiebbc Andrei Troie added a comment - - edited

          +1 Josh Chandler

          I am also in the same situation. I have a jenkins server with mostly freestyle jobs and we've recently decided to migrate to using pipelines.

          For testing, I set up a multibranch pipeline that builds the same repo as one of my freestyle jobs. The freestyle jobs get triggered just fine when the Github webhook gets received, the items under the multibranch pipeline do not. Just as Josh Chandler says, the log indicates that a POST has been receieved (as per the code here) but then nothing happens.

          As far as I can tell the problem occurs slightly further down, here, which is called from here. As you can see, the code in triggerFrom does the following check: if (item instanceof ParameterizedJobMixIn.ParameterizedJob), so only items that end up having the correct inheritance hierarchy can get triggered by this code, because otherwise they'll end up failing this null check.

          I then verified this by using my jenkins script console and running the following script:

          jenkinsInstance = jenkins.model.Jenkins.instance
          
          parametrizedJobMixinItems = jenkinsInstance.getItems(ParameterizedJobMixIn.ParameterizedJob.class)
          
          parametrizedJobMixinItems.each { println(it) } 
          

          and sure enough, I could only see my freestyle jobs there, not my multibranch pipeline items as well.

          You could say that ultimately the responsibility lies with the creators of the multibranch pipeline, that they didn't respect the correct inheritance hierarchy, but the fact remains that as it stands, the code in the github plugin cannot trigger multibranch pipeline items.

          Show
          andreitroiebbc Andrei Troie added a comment - - edited +1 Josh Chandler I am also in the same situation. I have a jenkins server with mostly freestyle jobs and we've recently decided to migrate to using pipelines. For testing, I set up a multibranch pipeline that builds the same repo as one of my freestyle jobs. The freestyle jobs get triggered just fine when the Github webhook gets received, the items under the multibranch pipeline do not. Just as Josh Chandler says, the log indicates that a POST has been receieved (as per the code here ) but then nothing happens. As far as I can tell the problem occurs slightly further down, here , which is called from here . As you can see, the code in triggerFrom does the following check: if (item instanceof ParameterizedJobMixIn.ParameterizedJob) , so only items that end up having the correct inheritance hierarchy can get triggered by this code, because otherwise they'll end up failing this null check . I then verified this by using my jenkins script console and running the following script: jenkinsInstance = jenkins.model.Jenkins.instance parametrizedJobMixinItems = jenkinsInstance.getItems(ParameterizedJobMixIn.ParameterizedJob.class) parametrizedJobMixinItems.each { println(it) } and sure enough, I could only see my freestyle jobs there, not my multibranch pipeline items as well. You could say that ultimately the responsibility lies with the creators of the multibranch pipeline, that they didn't respect the correct inheritance hierarchy, but the fact remains that as it stands, the code in the github plugin cannot trigger multibranch pipeline items.
          Hide
          integer Kanstantsin Shautsou added a comment -

          MultibranchPipepline doesn't use gitscm, it totally separate code that works on their own triggers/plugins. Please fill issues to workflow.
          Github-plugin provides generic API for plugins, but nobody uses it and implements their own bicycles. Starting from this time there is no sense to make one powerful plugin as we thought before. If you don't like this triggering algorithm - don't use it. You can implement one more trigger way by using eventing APIs.
          Hint: on screenshot https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Integration+Plugin that triggers jobs as i wanted without sticking to gitscm at all and in theory it should work with "worfklow" (again mutlibranch is totally different APIs, if somebody exposed not suitable types in workflow-multibranch for not siutable triggers, then it their bugs) and workflow was known to be broken because they did hacks for triggers - fix was in one of latest releases. But again there is no any useful information in this issue or in comments. Please follow https://wiki.jenkins-ci.org/display/JENKINS/How+to+report+an+issue

          Show
          integer Kanstantsin Shautsou added a comment - MultibranchPipepline doesn't use gitscm, it totally separate code that works on their own triggers/plugins. Please fill issues to workflow. Github-plugin provides generic API for plugins, but nobody uses it and implements their own bicycles. Starting from this time there is no sense to make one powerful plugin as we thought before. If you don't like this triggering algorithm - don't use it. You can implement one more trigger way by using eventing APIs. Hint: on screenshot https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Integration+Plugin that triggers jobs as i wanted without sticking to gitscm at all and in theory it should work with "worfklow" (again mutlibranch is totally different APIs, if somebody exposed not suitable types in workflow-multibranch for not siutable triggers, then it their bugs) and workflow was known to be broken because they did hacks for triggers - fix was in one of latest releases. But again there is no any useful information in this issue or in comments. Please follow https://wiki.jenkins-ci.org/display/JENKINS/How+to+report+an+issue
          Hide
          jachandler Josh Chandler added a comment -

          The word "generic" doesn't even occur on this page until you get to the comments: https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin

          I take issue with the sentiment that "nobody uses [the generic APIs]" because, in fact, the plugin documentation explicitly states that it does, in that it is able to trigger webhooks. If that is not the case, the plugin needs to be deprecated for end-user consumption and the documentation changed. There is nothing on the github-plugin page to indicate that an installable plugin is just an abstraction that I shouldn't be using for the purpose stated by the documentation.

          This functionality was guaranteed up until workflow. Kirill did not protest the use of the plugin in the way I have specified, leading me to believe this was expected behavior until now. If that was not the case, I would love to know why no one said anything to the contrary for seven months until you jumped on this thread. The very fact that of 19 watchers of this issue, that no one but you knew about this, is pretty incredible. In fact, if you ask google "jenkins github push trigger": guess what comes up as the very first result?:

          "Starting from this time" does not magically reconcile the fact that this bug was filed under completely different auspices seven months ago. If I am totally incorrect and this is the direction that the authors are taking with respect to their plugins, there is still a bug in that the documentation for the github-plugin needs to be changed to tell us we shouldn't be using it this way, and to point us to the appropriate plugins.

          Show
          jachandler Josh Chandler added a comment - The word "generic" doesn't even occur on this page until you get to the comments: https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin I take issue with the sentiment that "nobody uses [the generic APIs] " because, in fact, the plugin documentation explicitly states that it does , in that it is able to trigger webhooks. If that is not the case, the plugin needs to be deprecated for end-user consumption and the documentation changed. There is nothing on the github-plugin page to indicate that an installable plugin is just an abstraction that I shouldn't be using for the purpose stated by the documentation. This functionality was guaranteed up until workflow. Kirill did not protest the use of the plugin in the way I have specified, leading me to believe this was expected behavior until now. If that was not the case, I would love to know why no one said anything to the contrary for seven months until you jumped on this thread. The very fact that of 19 watchers of this issue, that no one but you knew about this, is pretty incredible. In fact, if you ask google "jenkins github push trigger": guess what comes up as the very first result?: "Starting from this time" does not magically reconcile the fact that this bug was filed under completely different auspices seven months ago . If I am totally incorrect and this is the direction that the authors are taking with respect to their plugins, there is still a bug in that the documentation for the github-plugin needs to be changed to tell us we shouldn't be using it this way, and to point us to the appropriate plugins.
          Hide
          integer Kanstantsin Shautsou added a comment -

          Because jenkins INFRA is not suitable for maintaining. I switched assign to Kirill Merkushev but i can't have notifications for issues. So after making review and releases i decided to check issues. I provided hints and description, i don't want discuss this issue anymore because issue complain is about not github-plugin. Trigger description will be updated as it seems that people still confused and doesn't read documentation that describes that this pushtrigger works only with gitscm.
          Most of jenkins plugins documentation is pure because done by developers for developers. Last year documentation was updated. Will review and update when i will have time.

          Show
          integer Kanstantsin Shautsou added a comment - Because jenkins INFRA is not suitable for maintaining. I switched assign to Kirill Merkushev but i can't have notifications for issues. So after making review and releases i decided to check issues. I provided hints and description, i don't want discuss this issue anymore because issue complain is about not github-plugin. Trigger description will be updated as it seems that people still confused and doesn't read documentation that describes that this pushtrigger works only with gitscm. Most of jenkins plugins documentation is pure because done by developers for developers. Last year documentation was updated. Will review and update when i will have time.
          Hide
          integer Kanstantsin Shautsou added a comment -

          Checked wiki page - everything described right. UI text will be changed later.

          Show
          integer Kanstantsin Shautsou added a comment - Checked wiki page - everything described right. UI text will be changed later.
          Hide
          martinmine Martin added a comment - - edited

          In case someone are still having problems with this, here is a small example on how to use pipelines with webhooks:

          properties([pipelineTriggers([githubPush()])])
          
          node {
              git url: 'https://github.com/someone/something.git', branch: 'master'
          }
          

          This didn't work with the regular SCM checkout scm: [$class: 'GitSCM', ... 

          Also note that the job has to be executed manually one time in order for the push trigger and the git repo to be registered. Maybe this is worth mentioning on the Wiki as this is entirely undocumented and quite important for those of us not being able to use multibranch pipelines?

          Show
          martinmine Martin added a comment - - edited In case someone are still having problems with this, here is a small example on how to use pipelines with webhooks: properties([pipelineTriggers([githubPush()])]) node { git url: 'https: //github.com/someone/something.git' , branch: 'master' } This didn't work with the regular SCM checkout scm: [$class: 'GitSCM', ...  Also note that the job has to be executed manually one time in order for the push trigger and the git repo to be registered. Maybe this is worth mentioning on the Wiki as this is entirely undocumented and quite important for those of us not being able to use multibranch pipelines?

            People

            Assignee:
            lanwen Kirill Merkushev
            Reporter:
            jachandler Josh Chandler
            Votes:
            7 Vote for this issue
            Watchers:
            20 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: