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

P4 Trigger (/p4/change) Doesn't Detect p4port

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • p4-plugin
    • Jenkins ver. 2.19.2
      Peforce Plugin ver. 1.4.8
      Windows Server 2012

      Hi all,

      We are unable to get P4 Triggered builds to work on our local Jenkin/Perforce setup. When the JSON payload is POST'd to /p4/change it does not trigger our builds which are set to "Perforce triggered build.", but using the "Manual Configuration for Trigger" does work. If I use the /p4/ url and the "Manual Configuration for Trigger" and specify the port as: "perf.mysite.com:1666", and the change as "200" (not entirely clear what this field is used for, any number seems to work) this will cause the build to correctly trigger and fire.

      We have tried both using cURL (as per the example) and Postman and neither of them can successfully trigger builds. This is the exact cUrl command we use:

      curl --header "Content-Type: application/json" --request POST --data "payload=

      {change:200,p4port:\"perf.mysite.com:1666\"}

      " http://jenkins.mysite.com:8192/p4/change

      And Postman:
      POST /p4/change HTTP/1.1
      Host: jenkins.mysite.com:8192
      Content-Type: application/json
      Cache-Control: no-cache
      Postman-Token: 8425cf56-212f-f0fa-7007-b70a4591565e

      payload=

      {"change":"500", "p4port" :"perf.mysite.com:1666"}

      Job Setup:
      It was set up as a freestyle job (inside of a folder, though moving the job to the root level does not resolve it) and the Perforce Credentials were chosen. A workspace name was assigned, and a View Mapping was applied. Under "Build Triggers", only "Perforce triggered build." is checked.

      Logs:
      When Postman is used to POST the JSON payload as a simple test-case the following is printed into the logs (note that this was POST'd multiple times with different change values):
      Nov 14, 2016 3:44:32 PM INFO org.jenkinsci.plugins.p4.trigger.P4Hook doChange
      Received trigger event:

      {"change":"202","p4port":"perf.mysite.com:1666"}

      Nov 14, 2016 3:44:48 PM INFO org.jenkinsci.plugins.p4.trigger.P4Hook doChange
      Received trigger event:

      {"change":500,"p4port":"perf.mysite.com:1666"}

      However, nothing in the logs happens after that. I know that the [probeJobs](https://github.com/jenkinsci/p4-plugin/blob/master/src/main/java/org/jenkinsci/plugins/p4/trigger/P4Hook.java#L92) function works, as the Manual Trigger also invokes it and that is successfully printed.

      If I run the "Manual Configuration for Trigger" via the webpage, the following is printed into the logs:
      Nov 14, 2016 3:49:57 PM INFO org.jenkinsci.plugins.p4.trigger.P4Hook doChangeSubmit
      Manual trigger event:
      Nov 14, 2016 3:49:57 PM INFO org.jenkinsci.plugins.p4.trigger.P4Hook probeJobs
      P4: probing: MY_PROJECT
      Nov 14, 2016 3:49:57 PM INFO org.jenkinsci.plugins.p4.trigger.P4Trigger poke
      P4: poking: MY_PROJECT
      Nov 14, 2016 3:50:04 PM INFO org.jenkinsci.plugins.p4.tasks.CheckoutTask getBuildChange
      getBuildChange:return:726

      The only thing I can think of at this point is that it is not correctly retrieving the string for "p4port" variable, thus it never runs probeJobs when called from doChange. I cannot get it to print "p4port must be specified" in the logs, however I do not know if setting Jenkins log to /all includes Fine level logging or not. I cannot think of any reason the submitted JSON payloads would not work otherwise.

          [JENKINS-39734] P4 Trigger (/p4/change) Doesn't Detect p4port

          Rob Petti added a comment -

          perforce-plugin has no such functionality, and the latest version of it is 1.3.36, which is far less than what you've listed as having. I'm going to assume this was filed for the wrong plugin.

          Rob Petti added a comment - perforce-plugin has no such functionality, and the latest version of it is 1.3.36, which is far less than what you've listed as having. I'm going to assume this was filed for the wrong plugin.

          Matt Hoffman added a comment -

          rpetti I definitely did, I apologize! Thank you for the re-assignment!

          Matt Hoffman added a comment - rpetti I definitely did, I apologize! Thank you for the re-assignment!

          Paul Allen added a comment -

          Hi Matt,

          The P4PORT must match exactly the String used in your credential. However, if it works from the P4 Trigger button then the same value should in the payload from cURL.

          Depending on your Jenkins version and security settings you may need to add a CRUM, now documented in setup guide:
          https://github.com/jenkinsci/p4-plugin/blob/master/SETUP.md#triggering

          The 'change' parameter is not used; polling logic is now detects changes and starts the build. This might even be your issue, is there a real change to build?

          Kind regards,
          Paul

          Paul Allen added a comment - Hi Matt, The P4PORT must match exactly the String used in your credential. However, if it works from the P4 Trigger button then the same value should in the payload from cURL. Depending on your Jenkins version and security settings you may need to add a CRUM, now documented in setup guide: https://github.com/jenkinsci/p4-plugin/blob/master/SETUP.md#triggering The 'change' parameter is not used; polling logic is now detects changes and starts the build. This might even be your issue, is there a real change to build? Kind regards, Paul

          Matt Hoffman added a comment -

          Hey Paul,

          The P4PORT matches exactly in all three places: Inside the P4 Credentials, inside the Manual Configuration for Trigger, and inside the JSON payload with no extra prefixes, postfixes, etc. We have disabled the CRSF protection (so no CRUMB is required) as we were originally getting error messages about the lack of a CRUMB when sending it via PostMan.

          I have ensured that there is a real change to build by checking out a file and submitting the change request each time I attempt to make the build. However, shouldn't it print out that it is probing/poking the projects every time it gets the request to determine if there is a change? Using the "doChange" function seems to result in no probing/poking at all.

          I added some additional log debugging and compiled the plugin and came up with the following knowledge:
          Both doChange and doChangeSubmit call probeJobs.
          When doChange calls probeJobs, Jenkins.getInstance().getAllItems(Job.class) returns no entries.
          When doChangeSubmit calls probeJObs, Jenkins.getInstance().getALlItems(Job.class) returns 10 entries (all jobs in Jenkins).

          There is something about the execution flow caused by doChange which is causing Jenkins to not think they are are any jobs. I'm at a loss here as I don't know enough about Jenkins plugins unfortunately!

          Matt Hoffman added a comment - Hey Paul, The P4PORT matches exactly in all three places: Inside the P4 Credentials, inside the Manual Configuration for Trigger, and inside the JSON payload with no extra prefixes, postfixes, etc. We have disabled the CRSF protection (so no CRUMB is required) as we were originally getting error messages about the lack of a CRUMB when sending it via PostMan. I have ensured that there is a real change to build by checking out a file and submitting the change request each time I attempt to make the build. However, shouldn't it print out that it is probing/poking the projects every time it gets the request to determine if there is a change? Using the "doChange" function seems to result in no probing/poking at all. I added some additional log debugging and compiled the plugin and came up with the following knowledge: Both doChange and doChangeSubmit call probeJobs. When doChange calls probeJobs, Jenkins.getInstance().getAllItems(Job.class) returns no entries. When doChangeSubmit calls probeJObs, Jenkins.getInstance().getALlItems(Job.class) returns 10 entries (all jobs in Jenkins). There is something about the execution flow caused by doChange which is causing Jenkins to not think they are are any jobs. I'm at a loss here as I don't know enough about Jenkins plugins unfortunately!

          Paul Allen added a comment -

          I should have checked this earlier; are you using a FreeStyle Job or Pipeline? If the latter you will need the latest patch 1.4.9 (released today).

          Paul Allen added a comment - I should have checked this earlier; are you using a FreeStyle Job or Pipeline? If the latter you will need the latest patch 1.4.9 (released today).

          Matt Hoffman added a comment -

          It is a freestyle job.

          Matt Hoffman added a comment - It is a freestyle job.

            p4paul Paul Allen
            heliosmatt Matt Hoffman
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: