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

Perforce Clean Workspace "Full Wipe" should not add "-f" option to sync.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: p4-plugin
    • Labels:
    • Environment:
      Jenkins Version - 1.508
      Perforce Plugin Version - 1.3.26
      Platform - RHEL 6.3 x86_64
    • Similar Issues:

      Description

      We are trying to run builds from Perforce read-only replica server which requires "-p" option since its a read-only. At the same time we want to clean the workspace before each build with "Full Wipe" option.

      Perforce sync fails when using "Clean Workspace Before Each Build > Full Wipe" and "-p" option. Apparently "Full Wipe" is adding "-f" to the sync which makes it incompatible with "-p" which then fails the sync.

      The full wipe should not assume that user wants to force sync the workspace.

        Attachments

          Activity

          Hide
          rpetti Rob Petti added a comment -

          Yes, actually, it should assume a force sync, otherwise the user won't get all the files unless their client's have table is also cleared, which the plugin doesn't do. Simply preventing a force sync from occurring will break the clean functionality for the majority of users.

          I believe this is a bug in Perforce itself. '-f' and '-p' should not conflict with each other, as their functionality is not mutually exclusive. One option doesn't record the new state of the client while syncing, and the other syncs files even if the client reports them as being synced already.

          Show
          rpetti Rob Petti added a comment - Yes, actually, it should assume a force sync, otherwise the user won't get all the files unless their client's have table is also cleared, which the plugin doesn't do. Simply preventing a force sync from occurring will break the clean functionality for the majority of users. I believe this is a bug in Perforce itself. '-f' and '-p' should not conflict with each other, as their functionality is not mutually exclusive. One option doesn't record the new state of the client while syncing, and the other syncs files even if the client reports them as being synced already.
          Hide
          rpetti Rob Petti added a comment -

          Perhaps unsurprisingly, Perforce will not change this, as they believe it will cause issues with other end users. There's really no way around this except not putting in the -f flag when -p is enabled under any circumstances, but even that has issues if the user doesn't follow standard practice by either always using -p, or never using -p.

          Personally, I'd recommend using a quick clean instead of a full wipe as a workaround until someone can fix this in the plugin.

          Show
          rpetti Rob Petti added a comment - Perhaps unsurprisingly, Perforce will not change this, as they believe it will cause issues with other end users. There's really no way around this except not putting in the -f flag when -p is enabled under any circumstances, but even that has issues if the user doesn't follow standard practice by either always using -p, or never using -p. Personally, I'd recommend using a quick clean instead of a full wipe as a workaround until someone can fix this in the plugin.
          Hide
          arash_m arash m added a comment -

          Thanks for the update Rob. We can try the quick clean option.

          But I'm not sure if there will be any issues since we're planning to use this against a read only replica perforce instance, where the client workspace won't have any status of the files synced on a host. If the quickclean option only tries to get a list of the files a client workspace should have, it should work.

          But if it tries to check for status of sync or revision, then it likely won't work. Which might be what happens when the "Restore Changed/Deleted Files" option is checked with the quick clean. This option's description states

          "This option will scan for any tracked files that have been forcefully changed or removed by some other process (build scripts, compilers, engineers, etc) and force sync them from the repository."

          Either way, we'll give it a try.

          Show
          arash_m arash m added a comment - Thanks for the update Rob. We can try the quick clean option. But I'm not sure if there will be any issues since we're planning to use this against a read only replica perforce instance, where the client workspace won't have any status of the files synced on a host. If the quickclean option only tries to get a list of the files a client workspace should have, it should work. But if it tries to check for status of sync or revision, then it likely won't work. Which might be what happens when the "Restore Changed/Deleted Files" option is checked with the quick clean. This option's description states "This option will scan for any tracked files that have been forcefully changed or removed by some other process (build scripts, compilers, engineers, etc) and force sync them from the repository." Either way, we'll give it a try.
          Hide
          rpetti Rob Petti added a comment -

          It compares the contents of the workspace against the 'have' table, which is what normally gets updated on the server when you sync without -p. Since this table will presumably contain nothing on your workspace (assuming you have never synced it without -p), it will decide that all the files are untracked, and clean them as appropriate before syncing as it normally would with -p.

          It won't be as quick as if you were syncing using a write-through replica, but at least it should be safe.

          Show
          rpetti Rob Petti added a comment - It compares the contents of the workspace against the 'have' table, which is what normally gets updated on the server when you sync without -p. Since this table will presumably contain nothing on your workspace (assuming you have never synced it without -p), it will decide that all the files are untracked, and clean them as appropriate before syncing as it normally would with -p. It won't be as quick as if you were syncing using a write-through replica, but at least it should be safe.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            manvendra_singh Manvendra Singh
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated: