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

Perforce plugin should do validation of configuration options

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • None
    • Platform: All, OS: All

      • Verify the p4 binary exists.
      • Warn if another job has the same client name as the current one.
      • Try to login with the user credentials.
      • Verify the depot path is valid.

          [JENKINS-2948] Perforce plugin should do validation of configuration options

          Un-assigning this from digerata per request by him.

          Kohsuke Kawaguchi added a comment - Un-assigning this from digerata per request by him.

          torbent added a comment -

          Careful. Any of these might fail if the master and slaves aren't identical, unless the validation takes place on the specific slave to be used (which there's no way to guarantee?).
          It's probably better to just improve the detection and reporting of these errors. Currently the plugin is a bit lacking in those departments.

          torbent added a comment - Careful. Any of these might fail if the master and slaves aren't identical, unless the validation takes place on the specific slave to be used (which there's no way to guarantee?). It's probably better to just improve the detection and reporting of these errors. Currently the plugin is a bit lacking in those departments.

          Frank Merrow added a comment - - edited

          We have started adding the following to all jobs:

          p4 login -s
          IF ERRORLEVEL 1 EXIT %ERRORLEVEL%

          We have tickets setup on all Jenkins and would expect this to NEVER fail . . . but of course it does on occasion because somebody does something to cause a logout.

          The reason I've posted here, is that even putting this at the start of every job is not enough . . . We really want this done BEFORE all the stuff your plugin does to get the job started . . . and in fact, it would be nice if polling itself could do something similar . . . though in that case where do you report the error?

          It would be nice to be able to check as "user should already be logged in" check box and have you add a bunch of checking for this . . . the error messages we get now are often obscure and don't immediately lead the uninitiated to the conclusion that the automation username need to be logged in again.

          IN FACT . . . I'm way out there now, but just a thought . . . one of the annoying things about this happening is that when a single slave has a problem like this, a whole bunch of work will "abort into that slave" . . . it would be nice if when a username isn't logged in, you could affect the scheduling too so that host wasn't used until the username is logged back in or perhaps disable the slave until somebody can bring Perforce on-line again.

          Voted and Watched

          Frank Merrow added a comment - - edited We have started adding the following to all jobs: p4 login -s IF ERRORLEVEL 1 EXIT %ERRORLEVEL% We have tickets setup on all Jenkins and would expect this to NEVER fail . . . but of course it does on occasion because somebody does something to cause a logout. The reason I've posted here, is that even putting this at the start of every job is not enough . . . We really want this done BEFORE all the stuff your plugin does to get the job started . . . and in fact, it would be nice if polling itself could do something similar . . . though in that case where do you report the error? It would be nice to be able to check as "user should already be logged in" check box and have you add a bunch of checking for this . . . the error messages we get now are often obscure and don't immediately lead the uninitiated to the conclusion that the automation username need to be logged in again. IN FACT . . . I'm way out there now, but just a thought . . . one of the annoying things about this happening is that when a single slave has a problem like this, a whole bunch of work will "abort into that slave" . . . it would be nice if when a username isn't logged in, you could affect the scheduling too so that host wasn't used until the username is logged back in or perhaps disable the slave until somebody can bring Perforce on-line again. Voted and Watched

          Rob Petti added a comment -

          Frank I'm not sure I understand what you are saying... What does any of that have to do with form validation? It sounds more like you are having login issues. If a ticket isn't available, then the plugin will just login normally, so I'm not sure why you are having problems. Please feel free to send me an email if you need help debugging this further.

          Rob Petti added a comment - Frank I'm not sure I understand what you are saying... What does any of that have to do with form validation? It sounds more like you are having login issues. If a ticket isn't available, then the plugin will just login normally, so I'm not sure why you are having problems. Please feel free to send me an email if you need help debugging this further.

            Unassigned Unassigned
            mdonohue mdonohue
            Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: