If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 17/Mar/16 02:19 AM
Updated: 17/Mar/16 02:19 AM
|
|
Component/s: |
None
|
Affects Version/s: |
None
|
Fix Version/s: |
None
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
This is a request to convert / upgrade the built-in Perforce support to use the native P4Java interface, rather than manually assembling and executing commands through the command-line interface.
The primary reason for this is that it would allow for deeper, more advanced interaction with the Perforce server for cases where it's necessary to copy/merge between branches, create/populate new streams, and other similar tasks that are fairly commonplace in automated build environments. The only ways to achieve such an outcome currently are to either manually work with the command-line interface via groovy or to get P4Java on the server so that can be used. In either case, there's a lot of fiddling around having to get the perforce server, user, and client information out of the QuickBuild repository definition that has to be done in literally *every* groovy script you write.
This upgrade would allow for better integrated scriptability with the QuickBuild server by allowing it (given a new method) to return the P4Java server object for the specified repository that's already been created, connected, logged in, and is ready for use. This benefit would extend to the QuickBuild server too, though it's not likely to be too drastic.
The other reason for this is that, while not a common occurrence, it would help avoid compatibility issues with the format of the command-line interface's output (even when using ztags). This is something that I've encountered a couple times in my years working with Perforce, and can be a bit of a pain when dealing with servers that have a wide array of perforce clients installed.
Thanks,
-J. Mash
|
Description
|
This is a request to convert / upgrade the built-in Perforce support to use the native P4Java interface, rather than manually assembling and executing commands through the command-line interface.
The primary reason for this is that it would allow for deeper, more advanced interaction with the Perforce server for cases where it's necessary to copy/merge between branches, create/populate new streams, and other similar tasks that are fairly commonplace in automated build environments. The only ways to achieve such an outcome currently are to either manually work with the command-line interface via groovy or to get P4Java on the server so that can be used. In either case, there's a lot of fiddling around having to get the perforce server, user, and client information out of the QuickBuild repository definition that has to be done in literally *every* groovy script you write.
This upgrade would allow for better integrated scriptability with the QuickBuild server by allowing it (given a new method) to return the P4Java server object for the specified repository that's already been created, connected, logged in, and is ready for use. This benefit would extend to the QuickBuild server too, though it's not likely to be too drastic.
The other reason for this is that, while not a common occurrence, it would help avoid compatibility issues with the format of the command-line interface's output (even when using ztags). This is something that I've encountered a couple times in my years working with Perforce, and can be a bit of a pain when dealing with servers that have a wide array of perforce clients installed.
Thanks,
-J. Mash |
Show » |
No changes have yet been made on this issue.
|
|