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

v1.3.x perforce plugin doesn't work with the latest perforce 2012.2

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • None

      We’ve upgraded our perforce from 2012.1 to 2012.2, which supports ssl. But with the new version, the perforce plugin is having problem before the sync. It’s trying to run “p4 where” command at // level, instead of the changelist. This was a fixed bug back in 2011 in v1.2.9, which worked with the latest 2012.2. However, the newer 1.3.x won’t work. 1.3.x work fine with perforce 2012.1 with no problem. Upgraded to the latest jenkins, but no difference.

      copying a segment of the log:
      ===
      Started by user admin
      Building remotely on blinnv12g in workspace /scratch/linux86/jks/perforce_test2/dev
      Using remote perforce client: jkspilot2_p4-161040911
      [dev] $ /usr/local/bin/p4 workspace -o jkspilot2_p4-161040911
      [dev] $ /usr/local/bin/p4 login -p
      [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx workspace -o jkspilot2_p4-161040911
      Last build changeset: 277259
      [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx counter change
      [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx -s changes //jkspilot2_p4-161040911/...@277260,@277278
      [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx describe -s 277277
      [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx -G where //...
      Caught exception communicating with perforce. P4 Where Parsing Error: Some commands just want to watch the database churn.
      com.tek42.perforce.PerforceException: P4 Where Parsing Error: Some commands just want to watch the database churn.

      at hudson.plugins.perforce.PerforceSCMHelper.parseWhereMapping(PerforceSCMHelper.java:159)
      at com.tek42.perforce.parse.Changes.calculateWorkspacePaths(Changes.java:82)
      at com.tek42.perforce.parse.Changes.getChangelist(Changes.java:71)
      at com.tek42.perforce.parse.Changes.getChangelistsFromNumbers(Changes.java:425)
      at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:662)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1325)
      at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:682)
      at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:587)
      at hudson.model.Run.execute(Run.java:1543)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:236)
      ERROR: Unable to communicate with perforce. P4 Where Parsing Error: Some commands just want to watch the database churn.

      Email was triggered for: Failure
      Sending email for trigger: Failure
      Sending email to: s@xxx.com
      Finished: FAILURE
      ===

          [JENKINS-16512] v1.3.x perforce plugin doesn't work with the latest perforce 2012.2

          Rob Petti added a comment - - edited

          Where command has always been executed at that level, and will only ever return the Depot<>View<>Workspace map. This is a very low intensity command that simply generates a more useful version of your view. I invite you to try it for yourself.

          The issue is that your perforce server or client is returning an error with junk data: "Some commands just want to watch the database churn."

          I'm assuming this is part of some trigger that you or your administrators have added. You will need to remove it.

          Rob Petti added a comment - - edited Where command has always been executed at that level, and will only ever return the Depot<>View<>Workspace map. This is a very low intensity command that simply generates a more useful version of your view. I invite you to try it for yourself. The issue is that your perforce server or client is returning an error with junk data: "Some commands just want to watch the database churn." I'm assuming this is part of some trigger that you or your administrators have added. You will need to remove it.

          Sherrie Ma added a comment -

          Thanks, Rob. I've tried to use a lower version of this perforce plugin v1.2.9. It won't give this error. Particularly, when using v1.2.9, the "p4 -G where" command right before the error is like this:
          ===
          [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx -s sync //jenkinspilot2_test_p4-161040911/...@362136
          ===

          , instead of:
          ===
          [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx -s sync //...
          ===

          I find this very similar to a bug related to p4 where parsing that was fixed in v1.2.9, and it's indeed a working version for us.

          And if the breakage was caused by a trigger that worked with 2012.1 but wouldn't work with 2012.2, any suggestion of how to identify it?

          Thanks!

          Sherrie Ma added a comment - Thanks, Rob. I've tried to use a lower version of this perforce plugin v1.2.9. It won't give this error. Particularly, when using v1.2.9, the "p4 -G where" command right before the error is like this: === [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx -s sync //jenkinspilot2_test_p4-161040911/...@362136 === , instead of: === [dev] $ /usr/local/bin/p4 -P 6BD4xxxxxxxxxxxxxxxxxxxxxxx -s sync //... === I find this very similar to a bug related to p4 where parsing that was fixed in v1.2.9, and it's indeed a working version for us. And if the breakage was caused by a trigger that worked with 2012.1 but wouldn't work with 2012.2, any suggestion of how to identify it? Thanks!

          Rob Petti added a comment -

          That's a 'sync' command, not a 'where' command. The reason 1.2.9 works for you is because that version does not try to obtain the 'where' map.

          Ask your perforce administrators if they have any triggers that contain the phrase: "Some commands just want to watch the database churn." I have downloaded 2012.2, and have confirmed that this is NOT an error built-in to perforce, which means your admins are doing something to intentionally block certain commands.

          Rob Petti added a comment - That's a 'sync' command, not a 'where' command. The reason 1.2.9 works for you is because that version does not try to obtain the 'where' map. Ask your perforce administrators if they have any triggers that contain the phrase: "Some commands just want to watch the database churn." I have downloaded 2012.2, and have confirmed that this is NOT an error built-in to perforce, which means your admins are doing something to intentionally block certain commands.

          Tom Hollis added a comment -

          This issue has just occurred for me also, so it must be a perforce option as I get exactly the same string.

          For me

          p4 where
          works fine

          p4 where //...
          comes back with:
          Some commands just want to watch the database churn. Fix your workspace mapping.

          Are these command not equivalent? Is p4 where less intensive that p4 where //... and that is why our servers are complaining

          Tom

          Tom Hollis added a comment - This issue has just occurred for me also, so it must be a perforce option as I get exactly the same string. For me p4 where works fine p4 where //... comes back with: Some commands just want to watch the database churn. Fix your workspace mapping. Are these command not equivalent? Is p4 where less intensive that p4 where //... and that is why our servers are complaining Tom

          Rob Petti added a comment -

          That's very strange, because it works fine for me. 'p4 where //...' is extremely lightweight, and takes next to no time at all to execute, so I have no idea why your server would be blocking it. Can you try 'p4 where //<workspace>/...' and see if it returns the same thing?

          Rob Petti added a comment - That's very strange, because it works fine for me. 'p4 where //...' is extremely lightweight, and takes next to no time at all to execute, so I have no idea why your server would be blocking it. Can you try 'p4 where //<workspace>/...' and see if it returns the same thing?

          Tom Hollis added a comment -

          I would love to, but I spoke to the perforce administrators and they sorted it out.

          I can ask them what they did if that will help

          Tom

          Tom Hollis added a comment - I would love to, but I spoke to the perforce administrators and they sorted it out. I can ask them what they did if that will help Tom

          Rob Petti added a comment -

          That would help a lot, thanks!

          Rob Petti added a comment - That would help a lot, thanks!

          Rob Petti added a comment -

          My research has shown that this is actually caused by a naive broker configuration. One of the sample options that is normally commented out rejects ALL commands done on '//...', and returns the unprofessional looking error message outlined above. This is purely a configuration issue, but I'll see if we can change the command so this doesn't come up if others use this same configuration.

          Rob Petti added a comment - My research has shown that this is actually caused by a naive broker configuration. One of the sample options that is normally commented out rejects ALL commands done on '//...', and returns the unprofessional looking error message outlined above. This is purely a configuration issue, but I'll see if we can change the command so this doesn't come up if others use this same configuration.

          Oleg Nenashev added a comment -

          @Rob
          Are you going to fix this issue?
          P4 plugin seems to work properly with 2013.x, so it makes sense to add disclaimer to Wiki

          Oleg Nenashev added a comment - @Rob Are you going to fix this issue? P4 plugin seems to work properly with 2013.x, so it makes sense to add disclaimer to Wiki

          Rob Petti added a comment -

          The plugin works properly with 2012.2 as well. It's not caused by a version conflict; it's caused by a bad broker configuration that blindly rejects all operations on '//...'. It may be possible to use something other that //... (such as //workspace_name/...) but it requires non-trivial refactoring.

          Rob Petti added a comment - The plugin works properly with 2012.2 as well. It's not caused by a version conflict; it's caused by a bad broker configuration that blindly rejects all operations on '//...'. It may be possible to use something other that //... (such as //workspace_name/...) but it requires non-trivial refactoring.

            Unassigned Unassigned
            sherriexma Sherrie Ma
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: