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

P4 Publish Assets - Shelve Change uses questionable logic

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: p4-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.6.16
      P4 1.2.3
    • Similar Issues:

      Description

      Test case:

      • Freestyle job
      • * configured P4 SCM
      • * Build step: batchfile command to p4 edit a file in the configured workspace
      • * Post build action Perforce: Publish Assets using the same P4 config as the checkout, set to use the Shelve Change option.

      Ancillary details: P4 config was set to use a Static workspace, and job was configured to use a custom workspace directory which matched the Static workspace client root.

      Looking at the log for the Shelve step, it looks like it's doing quite the opposite of what I desire:

      • p4 revert -k
      • p4 sync -k
      • p4 reconcile -f
      • p4 opened

      I want:

      • p4 change -i
      • p4 reopen -c
      • p4 shelve -c
      • p4 revert (optional)

      In English: I simply want to shelve the files that were explicitly p4 edit/add'ed during the build. Currently, the Shelve post-build step wants to automatically collect and shelve every single file system delta generated in the workspace during the build - I positively do not want that, as it will catch generated intermediate and local settings files, which I would then have to filter out with another mechanism. Also, the p4 reconcile step currently used is untenable in a large workspace, as it can take a very long time to run.

      [Footnote: I am curious as to why the Shelve step uses reconcile behavior - this seems like an obscure specific use case compared to build steps being p4-aware.]

        Attachments

          Activity

          Hide
          p4paul Paul Allen added a comment -

          The shelve step was intended to gather up build results (assets) and shelve them for review.

          The shelve publish step should use a different workspace from the populate step. The view for this workspace should be very narrow (a Virtual stream, if using streams). Typically the view should be one or two files, limiting the files it will run the reconcile over.

          Files that are already versioned in Perforce (but modified by the build) should have the '+w' bit set (allowing modification, without the 'p4 edit' command). Then included in the scope of narrow view for the publish workspace.

          Show
          p4paul Paul Allen added a comment - The shelve step was intended to gather up build results (assets) and shelve them for review. The shelve publish step should use a different workspace from the populate step. The view for this workspace should be very narrow (a Virtual stream, if using streams). Typically the view should be one or two files, limiting the files it will run the reconcile over. Files that are already versioned in Perforce (but modified by the build) should have the '+w' bit set (allowing modification, without the 'p4 edit' command). Then included in the scope of narrow view for the publish workspace.
          Hide
          sumdumgai A C added a comment -

          That is less than ideal - every single Shelve Publish step in every single job will require its own unique workspace/viewspec, separate from the workspace/viewspec used to actually perform the build, but both mapped to the same client root. That seems like quite a roundabout way to accomplish what could just be specified with a filespec for the Shelve Publish step.

          Show
          sumdumgai A C added a comment - That is less than ideal - every single Shelve Publish step in every single job will require its own unique workspace/viewspec, separate from the workspace/viewspec used to actually perform the build, but both mapped to the same client root. That seems like quite a roundabout way to accomplish what could just be specified with a filespec for the Shelve Publish step.
          Hide
          p4paul Paul Allen added a comment -

          The publish workspace (and extra connection details) are there to allow users to publish assets to a different Perforce server or a different depot. Sometimes a different Perforce user is needed (e.g. write permissions for publish or to set the owner of the shelf). I agree it is convoluted, but I needed it to suit a wide variety of use cases.

          Show
          p4paul Paul Allen added a comment - The publish workspace (and extra connection details) are there to allow users to publish assets to a different Perforce server or a different depot. Sometimes a different Perforce user is needed (e.g. write permissions for publish or to set the owner of the shelf). I agree it is convoluted, but I needed it to suit a wide variety of use cases.

            People

            • Assignee:
              Unassigned
              Reporter:
              sumdumgai A C
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: