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

Provide a force-sync and/or clean pull feature for Perforce SCM checkouts

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      It seems like a "clean pull" option would be a useful general feature for all SCMs. One thing that I've seen done in the past is to do a "clean pull" every Nth build, or every build at a given time, so that would be a nice extension of this.

      It's a little tougher to do with Perforce than some other SCMs with its server-side state. Currently the Perforce plugin blocks workspace deletion form the UI. Making that work would also be nice.

      So, I think a complete "clean build" feature package might look like:
      1. enable manual workspace deletion in the UI
      2. add a sticky force-sync option to always pass -f to the sync
      3. add a sticky workspace clean option to nuke the workspace before syncing

      I think after running #1 or #3, a -f would have to be implicitly added to the next sync. That shouldn't be too hard.

      Also consider adding support for the new -p flag:

      Perforce 2007.2 introduced "-p" to p4 sync which makes it behave "just like the others". From p4 help sync :

      "The -p flag populates the client workspace, but does not update the
      server to reflect those updates. Any file that is already synced or
      opened will be bypassed with a warning message. This option is very
      useful for build clients or when publishing content without the
      requirement of saving the client workspace state."

        Attachments

          Activity

          Hide
          mdonohue mdonohue added a comment -

          These are all good ideas, but I think they would be more achievable as separate issues in Jira. The manual workspace deletion is completely separable from the others, for example.

          Show
          mdonohue mdonohue added a comment - These are all good ideas, but I think they would be more achievable as separate issues in Jira. The manual workspace deletion is completely separable from the others, for example.
          Hide
          smr99 smr99 added a comment -

          I'm particularly interested in "clean build" functionality where the entire workspace is deleted and re-pulled from perforce.
          This seems to overlap somehow with JENKINS-3966, though it's not clear what the status of the latter is.

          Show
          smr99 smr99 added a comment - I'm particularly interested in "clean build" functionality where the entire workspace is deleted and re-pulled from perforce. This seems to overlap somehow with JENKINS-3966 , though it's not clear what the status of the latter is.
          Hide
          javadude Carl Quinn added a comment -

          I agree that at some point the ideas should become separate Jira issues so that they can be tracked. But I just wanted to get the initial discussion summary recorded here so that we don't lose it. And as smr9 points out, item #3 is really covered by JENKINS-3966, but that will probably require item #1 to be implemented. They are a bit intertwined and need some detangling.

          Show
          javadude Carl Quinn added a comment - I agree that at some point the ideas should become separate Jira issues so that they can be tracked. But I just wanted to get the initial discussion summary recorded here so that we don't lose it. And as smr9 points out, item #3 is really covered by JENKINS-3966 , but that will probably require item #1 to be implemented. They are a bit intertwined and need some detangling.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : rpetti
          Path:
          trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java
          trunk/hudson/plugins/perforce/src/main/resources/hudson/plugins/perforce/PerforceSCM/config.jelly
          trunk/hudson/plugins/perforce/src/main/webapp/help/project.html
          trunk/hudson/plugins/perforce/src/test/java/hudson/plugins/perforce/PerforceSCMTest.java
          http://jenkins-ci.org/commit/28264
          Log:
          JENKINS-5182 adding support for the 'Wipe Out Workspace' operation, and adding new 'Always Force Sync' option

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java trunk/hudson/plugins/perforce/src/main/resources/hudson/plugins/perforce/PerforceSCM/config.jelly trunk/hudson/plugins/perforce/src/main/webapp/help/project.html trunk/hudson/plugins/perforce/src/test/java/hudson/plugins/perforce/PerforceSCMTest.java http://jenkins-ci.org/commit/28264 Log: JENKINS-5182 adding support for the 'Wipe Out Workspace' operation, and adding new 'Always Force Sync' option
          Hide
          rpetti Rob Petti added a comment -

          The above change just adds a handler that checks if the workspace is handled by the perforce plugin, and then sets one time force sync to true. If the plugin isn't handling the workspace, then it will block the wipe from taking place.

          This allows manual workspace deletion to work properly. If the core team implements an option to delete the workspace at the start of new builds, then this should all take care of itself. JENKINS-3966 should cover this.

          I've also added an "Always force sync" option. Note that this does NOT delete the workspace, it just always performs a force sync instead of a normal sync.

          Show
          rpetti Rob Petti added a comment - The above change just adds a handler that checks if the workspace is handled by the perforce plugin, and then sets one time force sync to true. If the plugin isn't handling the workspace, then it will block the wipe from taking place. This allows manual workspace deletion to work properly. If the core team implements an option to delete the workspace at the start of new builds, then this should all take care of itself. JENKINS-3966 should cover this. I've also added an "Always force sync" option. Note that this does NOT delete the workspace, it just always performs a force sync instead of a normal sync.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : rpetti
          Path:
          trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java
          trunk/hudson/plugins/perforce/src/main/resources/hudson/plugins/perforce/PerforceSCM/config.jelly
          trunk/hudson/plugins/perforce/src/main/webapp/help/wipeBeforeBuild.html
          trunk/hudson/plugins/perforce/src/test/java/hudson/plugins/perforce/PerforceSCMTest.java
          http://jenkins-ci.org/commit/28310
          Log:
          JENKINS-5182 adding an option to clean the entire workspace before syncing every build.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java trunk/hudson/plugins/perforce/src/main/resources/hudson/plugins/perforce/PerforceSCM/config.jelly trunk/hudson/plugins/perforce/src/main/webapp/help/wipeBeforeBuild.html trunk/hudson/plugins/perforce/src/test/java/hudson/plugins/perforce/PerforceSCMTest.java http://jenkins-ci.org/commit/28310 Log: JENKINS-5182 adding an option to clean the entire workspace before syncing every build.
          Hide
          rpetti Rob Petti added a comment -

          The option is there now, but I'll leave the bug open in the event that the core team implements the extension point mentioned in JENKINS-3966.

          Show
          rpetti Rob Petti added a comment - The option is there now, but I'll leave the bug open in the event that the core team implements the extension point mentioned in JENKINS-3966 .
          Hide
          rpetti Rob Petti added a comment -

          Resolving as postponed, since it looks like that extension point might take a while to be implemented.

          Show
          rpetti Rob Petti added a comment - Resolving as postponed, since it looks like that extension point might take a while to be implemented.

            People

            • Assignee:
              Unassigned
              Reporter:
              javadude Carl Quinn
            • Votes:
              4 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: