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

files in workspace area not deleted when p4 plugin creates a client spec

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • p4-plugin
    • None

      So we have a cluster of about a dozen build nodes and we let p4 plugin manage the client specs. A recent p4 plugin upgrade brought a change in the way those client specs are named. After upgrade, p4 plugin created new clients using the new naming convention (this part is fine), but it appeared that it did not delete the local workspace areas before creating new clients. The workspaces already contained files from the p4 clients as they were previously named. The new client got overlayed on top. Bad things started to happpen at this point as there were stray files in the workspace that were no longer tracked by p4 under the client that was in use.

      What I think is missing from p4 plugin is a bit of logic that wipes the local workspace if the plugin just created a p4 client. I don't think there are any conditions under which the existing contents of that directory are relevant if the p4 plugin just created a new client and mapped it to it.

          [JENKINS-6304] files in workspace area not deleted when p4 plugin creates a client spec

          Rob Petti added a comment -

          Yeah, that rename was a bad call on my part, but I don't think automatically deleting the contents of the workspace is a good solution. There are many people out there with complex setups, and a change like what is being proposed could seriously break them.

          The plugin is compatible with Hudson's "Wipe Out Workspace" function, so that can be used instead of doing it automatically.

          Rob Petti added a comment - Yeah, that rename was a bad call on my part, but I don't think automatically deleting the contents of the workspace is a good solution. There are many people out there with complex setups, and a change like what is being proposed could seriously break them. The plugin is compatible with Hudson's "Wipe Out Workspace" function, so that can be used instead of doing it automatically.

          ltrider added a comment -

          I hope you will re-consider. The problem is not limited to our exact scenario. You can readily reproduce this problem by starting a job with one client spec name and then changing your mind and modifying the client spec name in job config. Perforce plugin will happily create the new client spec, overlay it over existing files and lots of fun ensues as the user tries to figure out why Perforce has gone nuts.

          Hudson's "Wipe Out Workspace" function is not really a solution for this. In many cases the workspaces are far too large to be blowing them away on every build. Ours are 3GB+. We'd like to be able to tell Hudson to use the nuclear option only when necessary.

          I am having a hard time imagining a scenario where the user would configure Perforce plugin to manage the client spec for them and at the same time is doing something funky in the workspace such that letting the plugin blow away their workspace is not a good idea. However, if that is indeed a concern, perhaps an explicit option "let hudson manage my local workspace" could be added.

          ltrider added a comment - I hope you will re-consider. The problem is not limited to our exact scenario. You can readily reproduce this problem by starting a job with one client spec name and then changing your mind and modifying the client spec name in job config. Perforce plugin will happily create the new client spec, overlay it over existing files and lots of fun ensues as the user tries to figure out why Perforce has gone nuts. Hudson's "Wipe Out Workspace" function is not really a solution for this. In many cases the workspaces are far too large to be blowing them away on every build. Ours are 3GB+. We'd like to be able to tell Hudson to use the nuclear option only when necessary. I am having a hard time imagining a scenario where the user would configure Perforce plugin to manage the client spec for them and at the same time is doing something funky in the workspace such that letting the plugin blow away their workspace is not a good idea. However, if that is indeed a concern, perhaps an explicit option "let hudson manage my local workspace" could be added.

          Rob Petti added a comment -

          You'd like to be able to tell hudson to nuke the workpsace only when necessary, but you don't want to use the "Wipe Out Workspace" function? I'm not sure I follow. This is exactly what it does.

          I'm not referring to the Perforce Plugin option that wipes out the workspace every time, but the function inside Hudson itself that lets you wipe out the workspace when you need to. On the job page, click the 'Workspace' option on the left, and a "Wipe Out Workspace" option will appear below it. This is what I'm referring to. Is there a reason it won't work in your case?

          Rob Petti added a comment - You'd like to be able to tell hudson to nuke the workpsace only when necessary, but you don't want to use the "Wipe Out Workspace" function? I'm not sure I follow. This is exactly what it does. I'm not referring to the Perforce Plugin option that wipes out the workspace every time, but the function inside Hudson itself that lets you wipe out the workspace when you need to. On the job page, click the 'Workspace' option on the left, and a "Wipe Out Workspace" option will appear below it. This is what I'm referring to. Is there a reason it won't work in your case?

          Rob Petti added a comment -

          As an example of a project that will get screwed up in this instance, some people run their jobs in the same workspace root using the same client. A minor mistake in the configuration could result in the workspaces getting wiped for every job.

          Another example would be when files not in perforce are also needed in the workpsace root for building, such as code from other SCMs or 'secret' files such as passwords that people don't want to keep in perforce for security reasons.

          Rob Petti added a comment - As an example of a project that will get screwed up in this instance, some people run their jobs in the same workspace root using the same client. A minor mistake in the configuration could result in the workspaces getting wiped for every job . Another example would be when files not in perforce are also needed in the workpsace root for building, such as code from other SCMs or 'secret' files such as passwords that people don't want to keep in perforce for security reasons.

          ltrider added a comment -

          The one-time wipe function works if you assume that the user realizes that they need to invoke the wipe function. It certainly wasn't obvious to me that Perforce plugin wouldn't handle that. I understand that there are probably some users out there that would need a way to tell Perforce plugin to do less for them, but for majority of users, the setup is simple. The workspace is completely drawn from source control and when they tell Perforce plugin to manage their client spec for them, they assume that it will manage the local workspace as well.

          In general, it is not considered a good practice to map Perforce client to a directory that holds other content. Perhaps Perforce plugin should let user define a sub-directory under workspace where Perforce client should map to?

          I hope there is a way to make this work better for the majority of users.

          ltrider added a comment - The one-time wipe function works if you assume that the user realizes that they need to invoke the wipe function. It certainly wasn't obvious to me that Perforce plugin wouldn't handle that. I understand that there are probably some users out there that would need a way to tell Perforce plugin to do less for them, but for majority of users, the setup is simple. The workspace is completely drawn from source control and when they tell Perforce plugin to manage their client spec for them, they assume that it will manage the local workspace as well. In general, it is not considered a good practice to map Perforce client to a directory that holds other content. Perhaps Perforce plugin should let user define a sub-directory under workspace where Perforce client should map to? I hope there is a way to make this work better for the majority of users.

          Rob Petti added a comment -

          I'm just not keen on letting the plugin delete the entire workspace without user intervention. If you think of a better way to handle this without deleting the entire thing without confirmation, then by all means let me know, or better yet supply a patch.

          Ideally, the plugin should only delete the files that are being tracked by the old workspace, and leave all other files intact. I think this could be possible by syncing using the old client spec to file revision #0, but I'm not sure. It's probably worth looking into.

          Rob Petti added a comment - I'm just not keen on letting the plugin delete the entire workspace without user intervention. If you think of a better way to handle this without deleting the entire thing without confirmation, then by all means let me know, or better yet supply a patch. Ideally, the plugin should only delete the files that are being tracked by the old workspace, and leave all other files intact. I think this could be possible by syncing using the old client spec to file revision #0, but I'm not sure. It's probably worth looking into.

          Rob Petti added a comment -

          Changing priority to minor.

          Rob Petti added a comment - Changing priority to minor.

          Code changed in hudson
          User: : rpetti
          Path:
          trunk/hudson/plugins/perforce/src/main/webapp/help/clientNameFormat.html
          trunk/hudson/plugins/perforce/src/main/webapp/help/p4Client.html
          http://jenkins-ci.org/commit/30391
          Log:
          JENKINS-6304 making it more clear in the documentation about what happens when a client is renamed

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/webapp/help/clientNameFormat.html trunk/hudson/plugins/perforce/src/main/webapp/help/p4Client.html http://jenkins-ci.org/commit/30391 Log: JENKINS-6304 making it more clear in the documentation about what happens when a client is renamed

            Unassigned Unassigned
            ltrider ltrider
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: