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

integrate hudson perforce with multiple p4 locations

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • p4-plugin
    • None
    • Platform: All, OS: All

      The hudson perforce plugin is limited to synchronization with one
      directory/depot path. That is, when configuring a project, we will have to
      specify on the depot path line just the following:

      //depot/directory/...

      If there are multiple projects that we may or many not need to synchronize with,
      we will end up synching with much more than necessary.

      The situation we have is, we do have multiple projects, as follows:

      //depot/directory/project1/...
      //depot/directory/build_scripts_project1/...
      //depot/directory/project2/...
      //depot/directory/build_scripts_project2/...
      //depot/directory/project3/...
      //depot/directory/build_scripts_project3/...
      //depot/directory/common_resources/...
      //depot/directory/build_scripts_common_resources/...

      Now, all projects require the common resources (and it's corresponding build
      directory). So, far the only way to synch with each project is to use the depot
      path: //depot/directory/...

      This causes too much inefficiency in terms of space and time. Can you add a
      feature to allow us to specify individual projects/p4 modules as is the case in
      a normal p4 client spec?

      Thanks!

          [JENKINS-3745] integrate hudson perforce with multiple p4 locations

          martinfr62 added a comment -

          You can manually create the clientspec and use this in place of letting hudson
          manage the clientspec.

          The specify //depot/directory/... in hudson - but as the clientspec only
          contains

          //depot/directory/project1/...
          //depot/directory/build_scripts_project1/...
          //depot/directory/project2/...
          //depot/directory/build_scripts_project2/...
          //depot/directory/project3/...
          //depot/directory/build_scripts_project3/...
          //depot/directory/common_resources/...
          //depot/directory/build_scripts_common_resources/...

          This is what polling will check, and what will be sync'd against when the build
          occurs.

          martinfr62 added a comment - You can manually create the clientspec and use this in place of letting hudson manage the clientspec. The specify //depot/directory/... in hudson - but as the clientspec only contains //depot/directory/project1/... //depot/directory/build_scripts_project1/... //depot/directory/project2/... //depot/directory/build_scripts_project2/... //depot/directory/project3/... //depot/directory/build_scripts_project3/... //depot/directory/common_resources/... //depot/directory/build_scripts_common_resources/... This is what polling will check, and what will be sync'd against when the build occurs.

          martinfr62 added a comment -

          One correction - the root you need to specify in hudson is //... for multi-path
          clientspecs

          martinfr62 added a comment - One correction - the root you need to specify in hudson is //... for multi-path clientspecs

          mdonohue added a comment -

          Also see issue 1927

          mdonohue added a comment - Also see issue 1927

          jsynge added a comment -

          The (as yet unreleased) latest version of the perforce plugin addresses all of
          these problems. It allows for multiple mappings to be specified, or (as before)
          you can create your own multi-mapping clientspec, and tell the plugin not manage
          the clientspec. In the latter case, it is no longer necessary to specify //... as
          the depot path.

          jsynge added a comment - The (as yet unreleased) latest version of the perforce plugin addresses all of these problems. It allows for multiple mappings to be specified, or (as before) you can create your own multi-mapping clientspec, and tell the plugin not manage the clientspec. In the latter case, it is no longer necessary to specify //... as the depot path.

            Unassigned Unassigned
            aklintu aklintu
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: