Description

* 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

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.

Paul Allen
added a comment - 2015-06-08 23:01 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.

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.

A C
added a comment - 2015-06-08 21:19 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.

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.

Paul Allen
added a comment - 2015-06-08 21:07 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.