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

Add support for perforce shelve builds

    Details

    • Type: New Feature
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: p4-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      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

        Attachments

          Activity

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

          Show
          rpetti 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.
          Hide
          abigos 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

          Show
          abigos 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
          Hide
          rpetti 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.

          Show
          rpetti 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.
          Hide
          abigos 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.

          Show
          abigos 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.
          Hide
          jm0221 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
          Show
          jm0221 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

            People

            • Assignee:
              Unassigned
              Reporter:
              vbuzzsaw vbuzzsaw
            • Votes:
              22 Vote for this issue
              Watchers:
              24 Start watching this issue

              Dates

              • Created:
                Updated: