• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • None

      It would be really useful if the perforce plugin could add support for shelving – Functionality added perforce in version 2009.2.

      Here is a good blog writeup --http://blog.perforce.com/blog/?p=1872

      Many things hudson is great for is finding out if anyone "broke" the build by polling source repositories looking for commits and kicking off builds. But breaking builds and backing code is a pain sometimes. It would be even better if you could run a build in hudson BEFORE checking in your changelist to see if your changelist WOULD break the build and fix problems before they occur. That is exactly what perforce shelving does – It allows you to shelve your changelist – saving all your modifications to the server (without committing them), and then allowing others to pull down the shelved modified code and perform a build.

      I'm not sure if the underlying tek42 perforce client library you use supports shelving, but if so this would be really useful functionality.

      Thanks.

      Doug

          [JENKINS-7436] Add support for perforce shelve builds

          Ross Aribi added a comment -

          I've implemented a solution to enable a user to test builds using a "shelved" changelist if desired. This isn't a plugin, but rather a process incorporated within the build request form in Jenkins (Parameterized build).

          The Shelving process itself involves the following steps:
          p4 unshelve -f -s ${SHELVED_CHANGELIST} ${sourceCodePath}
          p4 revert -k ${sourceCodePath}

          Where:
          The -f flag forces the clobbering of any writeable but unopened files that are being unshelved. The -s flag specifies the number of the pending changelist that contains the shelved files.

          So, my implementation in Jenkins is as follows:
          1) Setup a parameterized build template
          2) Add a string parameter to the build template and name it something like: SHELEVED_CHANGELIST
          3) In the build section (I execute shell), put the following steps in the beginning of your build steps:

          1. Revert previous shelving activities
            p4 revert ${sourceCodePath}
          1. Unshelve if true
            if [ $SHELVED_CHANGELIST != "" ] ; then ( echo "User specified a shelved changelist, unshelving changelist ($SHELVED_CHANGELIST)";
            p4 unshelve -f -s $SHELVED_CHANGELIST ${sourceCodePath};
            )
            else (
            echo "Not running with a shelved changelist"; ); fi
          1. Now revert unshelve but KEEP the files locally
            p4 revert -k ${sourceCodePath}

          That's it. We've been using this solution successfully for about a year now and developers like it. All you need to do is to educate your developers on how to do shelving and create that changelist

          Ross Aribi added a comment - I've implemented a solution to enable a user to test builds using a "shelved" changelist if desired. This isn't a plugin, but rather a process incorporated within the build request form in Jenkins (Parameterized build). The Shelving process itself involves the following steps: p4 unshelve -f -s ${SHELVED_CHANGELIST} ${sourceCodePath} p4 revert -k ${sourceCodePath} Where: The -f flag forces the clobbering of any writeable but unopened files that are being unshelved. The -s flag specifies the number of the pending changelist that contains the shelved files. So, my implementation in Jenkins is as follows: 1) Setup a parameterized build template 2) Add a string parameter to the build template and name it something like: SHELEVED_CHANGELIST 3) In the build section (I execute shell), put the following steps in the beginning of your build steps: Revert previous shelving activities p4 revert ${sourceCodePath} Unshelve if true if [ $SHELVED_CHANGELIST != "" ] ; then ( echo "User specified a shelved changelist, unshelving changelist ($SHELVED_CHANGELIST)"; p4 unshelve -f -s $SHELVED_CHANGELIST ${sourceCodePath}; ) else ( echo "Not running with a shelved changelist"; ); fi Now revert unshelve but KEEP the files locally p4 revert -k ${sourceCodePath} That's it. We've been using this solution successfully for about a year now and developers like it. All you need to do is to educate your developers on how to do shelving and create that changelist

          Rob Petti added a comment -

          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?

          Rob Petti added a comment - 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

          Richard Taylor added a comment - 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

          Frank Merrow added a comment -

          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"

          Frank Merrow added a comment - 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"

          Rob Petti added a comment -

          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.

          Rob Petti added a comment - 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.

          Andy Bigos added a comment -

          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

          Andy Bigos added a comment - 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

          Rob Petti added a comment -

          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.

          Rob Petti added a comment - 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.

          Andy Bigos added a comment -

          >.. 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.

          Andy Bigos added a comment - >.. 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.

          John McGowan added a comment - - edited

          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

          John McGowan added a comment - - edited 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 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?

          Heiko Nardmann added a comment - 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?

            Unassigned Unassigned
            vbuzzsaw vbuzzsaw
            Votes:
            22 Vote for this issue
            Watchers:
            25 Start watching this issue

              Created:
              Updated: