Details
-
Improvement
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
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
- is blocking
-
JENKINS-7935 Allow sync against different Perforce Servers
-
- Resolved
-
-
-
- Closed
-
- is duplicated by
-
-
- Resolved
-
-
-
- Closed
-
- is related to
-
-
- Resolved
-
Activity
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.
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. JENKINS-5120 Wants node-level overrides for logical depot settings as well...
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.
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 
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?