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

Perforce should factor out global configuration to the global page

    XMLWordPrintable

Details

    • Improvement
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • p4-plugin
    • None
    • Platform: All, OS: All

    Description

      The p4 setup puts all configuration options on each project.
      The Jira plugin provides a nice interface for setting up the
      server/username/password in the global config, and then gives a dropdown for
      projects that want Jira integration to select the previously saved server
      settings. This looks like a good model for Perforce.

      The windows specific details seem out of place on the per-project setup screen
      as well, and could move to the global page. They could also use some
      reasonable default values, to help users get this right.

      Attachments

        Issue Links

          Activity

            Un-assigning this from digerata per request by him.

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

            Windows specific details, and the path to the perforce executable are not needed in the p4java version we're developing, so I think those will stay where they are for now.

            I do like that model of selecting from a predefined list of p4 servers that are defined globally, though. I'll look into it if i can find the time

            rpetti Rob Petti added a comment - Windows specific details, and the path to the perforce executable are not needed in the p4java version we're developing, so I think those will stay where they are for now. I do like that model of selecting from a predefined list of p4 servers that are defined globally, though. I'll look into it if i can find the time
            javadude Carl Quinn added a comment -

            It seems that there would be two distinct setting groups that could be managed globally:

            • node tool specifics: p4 path, Windows specific details
            • depot specifics: P4PORT, username, password, repository browser

            Then each project would select the desired logical depot, and the node's tools settings would define the node-local values for p4.

            javadude Carl Quinn added a comment - It seems that there would be two distinct setting groups that could be managed globally: node tool specifics: p4 path, Windows specific details depot specifics: P4PORT, username, password, repository browser Then each project would select the desired logical depot, and the node's tools settings would define the node-local values for p4.
            rpetti Rob Petti added a comment -

            JENKINS-5120 Wants node-level overrides for logical depot settings as well...

            rpetti Rob Petti added a comment - JENKINS-5120 Wants node-level overrides for logical depot settings as well...
            edrandall Ed Randall added a comment - - edited

            Our sysadmin just moved the perforce server hostname and won't add an alias.
            Now I have to update all 10 Jenkins job configurations to point at the new P4PORT.
            OK it doesn't happen very often but this feature would have been invaluable for solving that.
            I updated to plugin version 1.3.7 to get environment variable support but unfortunately it doesn't seem able to fetch P4PORT from a global environment variable and substitute in ${P4PORT}.
            If it could just pick up P4CONFIG and get the connection info from the external file that would have been better.

            edrandall Ed Randall added a comment - - edited Our sysadmin just moved the perforce server hostname and won't add an alias. Now I have to update all 10 Jenkins job configurations to point at the new P4PORT. OK it doesn't happen very often but this feature would have been invaluable for solving that. I updated to plugin version 1.3.7 to get environment variable support but unfortunately it doesn't seem able to fetch P4PORT from a global environment variable and substitute in ${P4PORT}. If it could just pick up P4CONFIG and get the connection info from the external file that would have been better.

            Has anyone found a solution to this? Recently our Perforce IT has mandated using AD accounts for Perforce authentication which expire every 90 days. This is causing us a lot of grief as we have 100 of build jobs across 4-5 Jenkins servers. It would be a great help if this enhancement could be implemented.
            On one defect trail I read we could even use global config, mask password and parameter substitution but note how that works. Any clue?

            shobhad Shobha Dashottar added a comment - Has anyone found a solution to this? Recently our Perforce IT has mandated using AD accounts for Perforce authentication which expire every 90 days. This is causing us a lot of grief as we have 100 of build jobs across 4-5 Jenkins servers. It would be a great help if this enhancement could be implemented. On one defect trail I read we could even use global config, mask password and parameter substitution but note how that works. Any clue?

            People

              Unassigned Unassigned
              mdonohue mdonohue
              Votes:
              6 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated: