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

Provide the option to use the client spec from the server verbatim

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Hudson 1.347
      Perforce Plugin 1.0.21
      Hosted on Linux FC11
      Perforce Server version: P4D/SOLARIS10X86_64/2008.1/176084 (2008/11/20)
    • Similar Issues:

      Description

      I am a first time user of Hudson. I have to say the tool was very easy to install and configure compare to other tools. The hardest part was understanding the way the build uses the Perforce plugin in terms of the workspace. When I created my first job I wanted Hudson to use a preexisting perforce workspace. I wanted to run builds in this preexisting workspace so I did not expect Hudson to try to change the root directory or viewspec or anything. In order to define this type of job you need to go into 'advanced' features and you need to configure a root directory and deselect 'let hudson manage my viewspec'. Well I did not see that option and when I ran the build very bad things happened to my workspace. I did recover but it was frustrating.

      So... The feature request is to provide the option to use a preexisting perforce workspace as it is defined on the server. User would specify the workspace name only. The job should not make any attempt to modify any portion of the client spec.

      I realize this may seem like a limited type of build but it has been very useful in terms of getting started with Hudson and gaining confidence in the tool.

        Attachments

          Activity

          Hide
          rpetti Rob Petti added a comment -

          Yes, by default it uses the options defined in the plugin configuration. I believe that's even in the documentation that's directly on the config screen.

          In any case, I'll move the 'let hudson manage workspace' option out of the advanced section to make it more visible, and I'll double check the documentation to make sure it's explaining things clearly. I'll also see if I can add an option like the one you suggested: to not modify the client in any way. It might take a while though, since it's pretty embedded in the code.

          Was this what happened in JENKINS-5838? Or did the plugin actually screw up and wipe out the workspace when it wasn't supposed to? If it was just a configuration issue, I'll close that bug.

          Show
          rpetti Rob Petti added a comment - Yes, by default it uses the options defined in the plugin configuration. I believe that's even in the documentation that's directly on the config screen. In any case, I'll move the 'let hudson manage workspace' option out of the advanced section to make it more visible, and I'll double check the documentation to make sure it's explaining things clearly. I'll also see if I can add an option like the one you suggested: to not modify the client in any way. It might take a while though, since it's pretty embedded in the code. Was this what happened in JENKINS-5838 ? Or did the plugin actually screw up and wipe out the workspace when it wasn't supposed to? If it was just a configuration issue, I'll close that bug.
          Hide
          mchartier mchartier added a comment -

          The problem I reported in JENKINS-5838 was not caused by a configuration issue. Hudson was installed, configured, and running about a week before the network went down. This is when the viewspec was wiped out.

          By the way, Hudson has already caught 4 build breakers already. In each case the developer was able to fix the build issue before anyone else synced their workspace. Feedback from the team has been very positive.

          Show
          mchartier mchartier added a comment - The problem I reported in JENKINS-5838 was not caused by a configuration issue. Hudson was installed, configured, and running about a week before the network went down. This is when the viewspec was wiped out. By the way, Hudson has already caught 4 build breakers already. In each case the developer was able to fix the build issue before anyone else synced their workspace. Feedback from the team has been very positive.
          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/dontUpdateClient.html
          trunk/hudson/plugins/perforce/src/test/java/hudson/plugins/perforce/PerforceSCMTest.java
          http://jenkins-ci.org/commit/28726
          Log:
          [FIXED JENKINS-5841] adding advanced option to disable client spec updating

          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/dontUpdateClient.html trunk/hudson/plugins/perforce/src/test/java/hudson/plugins/perforce/PerforceSCMTest.java http://jenkins-ci.org/commit/28726 Log: [FIXED JENKINS-5841] adding advanced option to disable client spec updating

            People

            • Assignee:
              rpetti Rob Petti
              Reporter:
              mchartier mchartier
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: