The version of the tek42 library we use probably doesn't support this at all, but we had branched it ourselves quite a while ago because the maintainer wasn't answering our calls regarding outstanding bugs. It's currently sitting with the rest of our source code, so we can modify it as we please.

I imagine we would need to allow a user to specify a shelved changelist or maybe a list of shelved changelists to pull down, probably through a job parameter. Does that sound like what you had in mind?

Yes, that's pretty much what I had envisioned. I would think min requirement would be to support one shelved changelist in the p4 configuration, and ensure this could be expressed as a token to be resolved from a build job parameter. I hadn't through through the idea of supporting multiple changelists. I suppose that would be possible. My concern would be that one might need to add extra logic to support the edge case that is a conflict in the multiple changelists, as the plugin would have no idea how to resolve it.

The main use case I would be trying to solve is where a developer in their local workspace has one changelist they are ready to check in, but in order to sanity test it, they could shelve that changelist and manually run a hudson build referring to the shelved changelist to verify it works outside of their local environment before committing it.

Quite frankly, I only have very cursory experience with this functionality, but could envision taking advantage of it and integrating it into our reg dev process if could be easily encorporated this plugin and as easy to use as the current plugin functionality (For example, I love how you make specifying workspaces so easy, creating them if they don't exist...)

As I get more experience with this functionality, I will add any additional comments I might have from my learning.

Thanks.

Sounds good. When I can find the time, I'll start looking into adding shelve functionality to the tek42 libraries we're using, then we can go from there.

OK, had a bit more time to work out the use case with some colleagues. What we are looking for is for the perforce-plugin to support the following command line equivalent:

p4 unshelve -s changelist [-f]

Details on the command can be found here: http://www.perforce.com/perforce/doc.current/manuals/cmdref/unshelve.html

The perforce plugin should behave as it always does, specifying a perforce client workspace and ensuring a p4 sync of that workspace prior to executing the build.

The additional work would be to support an additional option to specify a shelved changelist, and if specified, after syncing the workspace, the p4 unshelve -s changelist command would be run to bring down the pending changes and the perform the build. The -f option to that command would force an overwrite of any files with write access – not certain if that also needs to be an option to specify, or if we want to default the behavior.

A couple of additional thoughts on this:

1. the perforce-plugin is responsible for listing the changes since the last build – Might make sense to include in that set of changes in pending shelved changelist, and somehow indicate or highlight the changelist is pending/shelved.

2. upon completion of the build, there will be open files in the active perforce workspace. Need to determine the correct behavior to clean that up. Might make sense at the end of the build to discard those changes, and revert the workspace back prior to picking up the shelved changelist. Optionally, there was a suggestion that a user might want to indicate in the plugin confguration to commit the pending changlist if the build succeeds. That sounds cool but might be an V2 of the implementation as it might require a bit more work.

Regarding vbuzzsaw's comment:
"2. upon completion of the build, there will be open files in the active perforce workspace. Need to determine the correct behavior to clean that up. Might make sense at the end of the build to discard those changes, and revert the workspace back prior to picking up the shelved changelist. Optionally, there was a suggestion that a user might want to indicate in the plugin confguration to commit the pending changlist if the build succeeds."

The main use case we expect this functionality to be used for would be for a user to test their code changes by building and / or testing them on a central build / test engine prior to checking their code in.

If this is so, we'd expect the default behavior is to leave the shelved files checked out so that the user can determine based upon the result of the build/test whether to check them into the codeline or not. Reverting the codeline would not be the thing to do in this case, since the changes would be lost. An option to check-in automatically might be useful.

The user would then need direct access to the build machine, and the perforce user that hudson is running under. Reverting the hudson workspace is necessary so as not to pollute subsequent builds. Any commits (that aren't automatic) should be done by the user in their own workspace.

As I understand it, unshelving a changelist, then reverting the open files does not delete the shelved changelist. It will only return the workspace to the state it was at before the unshelving occurred, which is exactly what we want.

Regarding rpetti's comment - You are correct. Reversion on the build machine is the correct default behavior.

Has anyone looked in to this yet?

Not yet, unfortunately.

Yes, really unfortunate. Anyways, do you have a high level idea on how this can be achieved in some hacky way. I haven't looked at the plugin code yet but how easy or tough it is for some new person to understand the code and add this feature in?

It would be very difficult, especially for a new person. The underlying api would need to be extended to support shelving, you'd need to make new UI elements, and then you'd need to sort through the tangle of checkout code to figure out where it should live. And that's just for /unshelving/. There's still autocommitting, merging, and reverting that needs to be implemented as well, which would likely take the form of post-build plugins that will need to be written from scratch.

The easiest, hackiest way would be to simply add the shelving commands to your job as a build step. It should only require a few lines of bash or batch.

Wait, if you are leaving the unshelved files behind, doesn't that pollute the build environment for the next build? Or are you cleaning and force syncing on every build?

Hi. We've had a solution like this in mind for a while now. I've got a few questions.

p4 revert -k ${sourceCodePath}

When the next builds starts how do you ensure that the workspace does not contain any modified files? Even if the -k flag was not specified any files which where 'added' in the change list would still be left on the disc (and this would cause a problem for our build system). Our planned approach is to write a script which does the unshelve and also writes out a cleanup script which handles the adds and other cases not covered by p4 revert. Is there a simplere approach.

Many thanks
Rich

FWIW: This kind of a "pre-flight" feature has been on our To Do List for awhile now (just like this CR) . . . It would be great if you did it for us. <wink> Issue "voted" and "watched"

Richard,
This response is really late, but this is basically what I had in mind:

-If there is a changeset already unshelved from last build:
 --Issue 'p4 opened' to get list of added files
 --Issue 'p4 revert'
 --Cleanup added files, since they would be left behind otherwise
-Sync
-Unshelve
-Build

Note that nowhere would we use '-k'. That would put the workspace into an inconsistent state, and we can't have that.

Just bumping this issue as wondering if there has been any progress. It sounds like the way to get something going (at the moment) is as a build step, however it does really seem to fall in the domain of the scm plugin.

The complications seem to come from trying to be consistent when the workspace isn't cleaned, which is something I guess most people don't do as it's generally considered best practice to clean the workspace between builds. I would think this was especially true when dealing the pre-commit testing.

With that in mind, I wonder if it's possible to do an initial implementation that relies on having a clean workspace? E.g. if a shelved CL is provided (via a parameter) this overrides the clean workspace setting so that it always starts from a known state? That would remove some of the complexity and I guess meet most peoples use cases. Just an idea.

I'd be interesting to hear of any progress on the plugin side before we go ahead and implement this as a build step.

Ta
Andy

As far as I know, nobody has been working on this. We don't use shelving at my organization, so I can't justify using company time to implement it.

>.. I can't justify using company time to implement it.

Thanks for update Rob, we will look at implementing this via build steps in that case.

We've been doing precommit/shelved builds for a good while in a build step prior to the main job. Parameterized build with the p4 shelve number as input. I run "Run buildstep before SCM":

#!/bin/bash -ex

p4 revert ...

Then before the main build task I run this (this is on a clean and new workspace everytime btw):

if [ $SHELVE != 0 ]; then

1. Unshelve the p4 shelve list supplied in the parameter 'SHELVE'
   p4 unshelve -s $SHELVE
   if [ $? -ne 0 ]; then
   echo "Unshelving change $SHELVE hasn't worked, aborting"
   exit 1
   fi
   else
   echo "Input a value for the P4 shelve command or else you're just building the latest nightly code, which is covered in another job"
   exit 1
   fi

As unshelving can be done both for Freestyle jobs as well as for pipeline code ("p4unshelve") for a while now: why not close this ticket?