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

Perforce triggered build should not trigger polling on jobs unless there are changes related to that view

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

      The current implementation triggers polling on all jobs with Perforce Triggered Build enabled. This is fine for small installations with few check ins per day, but not for installations with hundreds of jobs. This can cause massive spikes in size increases for Perforce server logs.

      For example, if I check in a file to "//my_depot/..." I should trigger polling on a job with view:

      //my_depot/... //workspace_name/...
      

      However, I should not trigger polling on a job with view:

      //my_depot2/... //workspace_name/...
      

          [JENKINS-41764] Perforce triggered build should not trigger polling on jobs unless there are changes related to that view

          Robby Pocase added a comment - - edited

          Additionally, it should verify the change is actually associated with the right port. That overhaul is possibly out of scope of this improvement request.

          You might be able to accomplish that portion naively in the same request. If you retrieve the change in probeJobs using port and change you likely have a very high success ratio of matching the change to the server. If change is null, it's obviously a mismatch. If change isn't, then your depot path still has to match the jobs workspace view. I would be surprised if many Perforce deployments have large amounts of duplicated full depot paths on multiple servers.

          Robby Pocase added a comment - - edited Additionally, it should verify the change is actually associated with the right port. That overhaul is possibly out of scope of this improvement request. You might be able to accomplish that portion naively in the same request. If you retrieve the change in probeJobs using port and change you likely have a very high success ratio of matching the change to the server. If change is null, it's obviously a mismatch. If change isn't, then your depot path still has to match the jobs workspace view. I would be surprised if many Perforce deployments have large amounts of duplicated full depot paths on multiple servers.

          Is there any progress on this?

          Also not sure if it's related or not.. but I have a pipeline script job, that is set to "Perforce triggered build" and it never gets picked up when I send manual P4 Trigger.

           

          Alena Volarevic added a comment - Is there any progress on this? Also not sure if it's related or not.. but I have a pipeline script job, that is set to "Perforce triggered build" and it never gets picked up when I send manual P4 Trigger.  

          Also the jobs that are being triggered by preforce should be build no matter if they are using Source Code Management or not. 

          Like I have a job that is using the files from the perforce, but I am syncing the workspace files in the build process instead of source code managements portion. and I realized if I don't have source code management set to use perforce. the jobs wont be picked up when the P4 trigger is emitted... 

          Alena Volarevic added a comment - Also the jobs that are being triggered by preforce should be build no matter if they are using Source Code Management or not.  Like I have a job that is using the files from the perforce, but I am syncing the workspace files in the build process instead of source code managements portion. and I realized if I don't have source code management set to use perforce. the jobs wont be picked up when the P4 trigger is emitted... 

            Unassigned Unassigned
            rpocase Robby Pocase
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: