# Example YAML to get you started quickly. # Be aware that YAML has indentation based scoping. # Code completion support is available so start typing for available options. swagger: '2.0' # This is your document metadata info: title: Helix Web Services description: Provides HTTP Access to Helix Service Applications contact: name: Perforce Support email: support@perforce.com license: name: MIT version: "2016.1.0" schemes: ["http","https"] consumes: ["application/json"] produces: ["application/json"] securityDefinitions: ticket_auth: type: apiKey in: header name: Authorization description: | To use HWS, obtain a ticket using the /login method. security: - ticket_auth: [] parameters: server: name: server type: string in: path required: true description: | The server ID that we execute this particular method against. # Describe your paths here paths: #--------------------------------------------------------------------- # Branches #--------------------------------------------------------------------- /api/p4/v16.1/{server}/branches: get: operationId: listBranches description: | Lists available branches in the system. The resources of this list are summaries of branches in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of branches in the system. schema: type: array items: $ref: "#/definitions/BranchesCommand" post: operationId: addBranch description: | Creates a new branch specification, like the `p4 branch` command. parameters: - $ref: '#/parameters/server' - name: body in: body description: The branch specification. required: true schema: $ref: "#/definitions/BranchCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/branches/{branch}: get: operationId: getBranch description: | Returns the branch spec details of the particular branch. parameters: - $ref: '#/parameters/server' - name: branch in: path description: The branch ID required: true type: string responses: 200: description: Branch spec details schema: $ref: "#/definitions/BranchCommand" patch: operationId: updateBranch description: | Update branch specifications, similar to the `p4 branch` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: branch in: path description: The branch ID required: true type: string - name: body in: body required: true description: Fields of the branch to update schema: $ref: "#/definitions/BranchCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteBranch description: | Removes the branch specification, similar to the `p4 branch -d` command. parameters: - $ref: '#/parameters/server' - name: branch in: path description: The branch ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Changes #--------------------------------------------------------------------- /api/p4/v16.1/{server}/changes: get: operationId: listChanges description: | Lists available changes in the system. The resources of this list are summaries of changes in the system. parameters: - $ref: '#/parameters/server' - name: max in: query description: Limit the number of change results required: false type: integer - name: status in: query description: The status of the changes, e.g., `submitted` required: false type: string - name: user in: query description: The user's login who submitted the change required: false type: string - name: files in: query description: | Limit changes to the depot path expressions. See the link:http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_changes.html[changes] command description. required: false type: string responses: 200: description: Summaries of changes in the system. schema: type: array items: $ref: "#/definitions/ChangesCommand" post: operationId: addChange description: | Create a new changelist that can affect multiple files using different kinds of actions. If you require the ability to integrate or move, for example, you can use this method. parameters: - $ref: '#/parameters/server' - name: changelistRequest in: body description: Description of changes to make required: true schema: $ref: "#/definitions/ChangelistRequest" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/changes/{change}: get: operationId: getChange description: | Returns the change spec details of the particular change. parameters: - $ref: '#/parameters/server' - name: change in: path description: The change ID required: true type: string responses: 200: description: Change spec details schema: $ref: "#/definitions/ChangeCommand" #--------------------------------------------------------------------- # Clients #--------------------------------------------------------------------- /api/p4/v16.1/{server}/clients: get: operationId: listClients description: | Lists available clients in the system. The resources of this list are summaries of clients in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of clients in the system. schema: type: array items: $ref: "#/definitions/ClientsCommand" post: operationId: addClient description: | Creates a new client specification, like the `p4 client` command. parameters: - $ref: '#/parameters/server' - name: client in: body description: The client spec required: true schema: $ref: "#/definitions/ClientCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/clients/{client}: get: operationId: getClient description: | Returns the client spec details of the particular client. parameters: - $ref: '#/parameters/server' - name: client in: path description: The client ID required: true type: string responses: 200: description: Client spec details schema: $ref: "#/definitions/ClientCommand" patch: operationId: updateClient description: | Update client specifications, similar to the `p4 client` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: client in: path description: The client ID required: true type: string - name: body in: body required: true description: Fields of the client to update schema: $ref: "#/definitions/ClientCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteClient description: | Removes the client specification, similar to the `p4 client -d` command. parameters: - $ref: '#/parameters/server' - name: client in: path description: The client ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Commands #--------------------------------------------------------------------- /api/p4/v16.1/{server}/run/{command}: get: operationId: runCommand description: | Execute a Perforce command that requires no input. This only allows commands that have been whitelisted on your system. See the <> section for details. parameters: - $ref: '#/parameters/server' - name: command in: path description: The command name required: true type: string - name: arg in: query description: Command arguments required: false type: array items: type: string collectionFormat: multi responses: 200: description: Generic list of hashes response schema: $ref: '#/definitions/CommandResponse' post: operationId: runCommandWithInput description: | Execute a Perforce command that accepts input, like a spec. This only allows commands that have been whitelisted on your system. See the <> section for details. parameters: - $ref: '#/parameters/server' - name: command in: path description: The command name required: true type: string - name: arg in: query description: Command arguments required: false type: array items: type: string collectionFormat: multi - name: input in: body description: A hash used as input to the command required: false schema: $ref: '#/definitions/CommandRequest' responses: 200: description: Generic list of hashes response schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Counters #--------------------------------------------------------------------- /api/p4/v16.1/{server}/counters: get: operationId: listCounters description: | Lists available counters in the system. The resources of this list are summaries of counters in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of counters in the system. schema: type: array items: $ref: "#/definitions/Counter" /api/p4/v16.1/{server}/counters/{counter}: get: operationId: getCounter description: | Returns the counter spec details of the particular counter. parameters: - $ref: '#/parameters/server' - name: counter in: path description: The counter ID required: true type: string responses: 200: description: Counter spec details schema: $ref: "#/definitions/Counter" put: operationId: setCounter description: | Update counter specifications, similar to the `p4 counter` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: counter in: path description: The counter ID required: true type: string - name: body in: body required: true description: Fields of the counter to update schema: $ref: "#/definitions/Counter" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteCounter description: | Removes the counter specification, similar to the `p4 counter -d` command. parameters: - $ref: '#/parameters/server' - name: counter in: path description: The counter ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/counters/{counter}/increment: post: operationId: incrementCounter description: | Increments a numerical counter, similar to the `p4 counter -i` command. parameters: - $ref: '#/parameters/server' - name: counter in: path description: The counter ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Depots #--------------------------------------------------------------------- /api/p4/v16.1/{server}/depots: get: operationId: listDepots description: | Lists available depots in the system. The resources of this list are summaries of depots in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of depots in the system. schema: type: array items: $ref: "#/definitions/DepotsCommand" post: operationId: addDepot description: | Creates a new depot specification, like the `p4 depot` command. parameters: - $ref: '#/parameters/server' - name: depot in: body description: The depot spec required: true schema: $ref: "#/definitions/DepotCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/depots/{depot}: get: operationId: getDepot description: | Returns the depot spec details of the particular depot. parameters: - $ref: '#/parameters/server' - name: depot in: path description: The depot ID required: true type: string responses: 200: description: Depot spec details schema: $ref: "#/definitions/DepotCommand" patch: operationId: updateDepot description: | Update depot specifications, similar to the `p4 depot` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: depot in: path description: The depot ID required: true type: string - name: body in: body required: true description: Fields of the depot to update schema: $ref: "#/definitions/DepotCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteDepot description: | Removes the depot specification, similar to the `p4 depot -d` command. parameters: - $ref: '#/parameters/server' - name: depot in: path description: The depot ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Fixes #--------------------------------------------------------------------- /api/p4/v16.1/{server}/fixes/change/{change}: get: operationId: listChangeFixes description: | List of fixed jobs associated to the specified changelist. parameters: - $ref: '#/parameters/server' - name: change in: path description: The change ID required: true type: string responses: 200: description: List of fixed jobs with associated changelists. schema: type: array items: $ref: "#/definitions/FixesCommand" /api/p4/v16.1/{server}/fixes/job/{job}: get: operationId: listJobFixes description: | List of fixed changelists associated to the specified job. parameters: - $ref: '#/parameters/server' - name: job in: path description: The job ID required: true type: string responses: 200: description: List of fixed jobs with associated changelists. schema: type: array items: $ref: "#/definitions/FixesCommand" /api/p4/v16.1/{server}/fixes: get: operationId: listFixes description: | List of fixed changelists associated to the specified job. parameters: - $ref: '#/parameters/server' - name: includeIntegrated in: query description: | Includes any fixes made by changelists integrated into the specified files. required: false type: boolean - name: max in: query description: Limit the number of change results required: false type: integer - name: change in: query description: To list fixes for a specified changelist required: false type: string - name: job in: query description: To list fixes for a specified job required: false type: string - name: files in: query description: | Limit changes to the depot path expressions. See the link:http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_changes.html[changes] command description. required: false type: string responses: 200: description: List of fixed jobs with associated changelists. schema: type: array items: $ref: "#/definitions/FixesCommand" #--------------------------------------------------------------------- # Groups #--------------------------------------------------------------------- /api/p4/v16.1/{server}/groups: get: operationId: listGroups description: | Lists available groups in the system. The resources of this list are summaries of groups in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of groups in the system. schema: type: array items: $ref: "#/definitions/GroupsCommand" post: operationId: addGroup description: | Creates a new group specification, like the `p4 group` command. parameters: - $ref: '#/parameters/server' - name: body in: body description: The group spec required: true schema: $ref: "#/definitions/GroupCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/groups/{group}: get: operationId: getGroup description: | Returns the group spec details of the particular group. parameters: - $ref: '#/parameters/server' - name: group in: path description: The group ID required: true type: string responses: 200: description: Group spec details schema: $ref: "#/definitions/GroupCommand" patch: operationId: updateGroup description: | Update group specifications, similar to the `p4 group` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: group in: path description: The group ID required: true type: string - name: body in: body required: true description: Fields of the group to update schema: $ref: "#/definitions/GroupCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteGroup description: | Removes the group specification, similar to the `p4 group -d` command. parameters: - $ref: '#/parameters/server' - name: group in: path description: The group ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Jobs #--------------------------------------------------------------------- /api/p4/v16.1/{server}/jobs: get: operationId: listJobs description: | Lists available jobs in the system. The resources of this list are summaries of jobs in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of jobs in the system. schema: type: array items: $ref: "#/definitions/JobsCommand" post: operationId: addJob description: | Creates a new job specification, like the `p4 job` command. parameters: - $ref: '#/parameters/server' - name: job in: body description: The job spec required: true schema: $ref: "#/definitions/JobCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/jobs/{job}: get: operationId: getJob description: | Returns the job spec details of the particular job. parameters: - $ref: '#/parameters/server' - name: job in: path description: The job ID required: true type: string responses: 200: description: Job spec details schema: $ref: "#/definitions/JobCommand" patch: operationId: updateJob description: | Update job specifications, similar to the `p4 job` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: job in: path description: The job ID required: true type: string - name: jobCommand in: body required: true description: Fields of the job to update schema: $ref: "#/definitions/JobCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteJob description: | Removes the job specification, similar to the `p4 job -d` command. parameters: - $ref: '#/parameters/server' - name: job in: path description: The job ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/jobs/{job}/fixes/{change}: post: operationId: addJobFix description: | Adds a fix record to the job for a particular changelist. parameters: - $ref: '#/parameters/server' - name: job in: path description: The job ID required: true type: string - name: change in: path description: The change ID required: true type: string - name: status in: query type: string required: false description: | Specify the job status instead of using the default. The default is typically `closed` or some other value defined in the `Presets` field specified in the `p4 jobspec` form. If the changelist to which you're linking the job been submitted, the status value is immediately reflected in the job's status. If the changelist is pending, the job status is changed on submission of the changelist, provided that the -s option is also supplied to p4 submit and the desired status appears next to the job in the p4 submit form's Jobs: field. To leave a job unchanged, use the special status of same. responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteJobFix description: | Removes the fix record association for the job for a particular changelist. parameters: - $ref: '#/parameters/server' - name: job in: path description: The job ID required: true type: string - name: change in: path description: The change ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Labels #--------------------------------------------------------------------- /api/p4/v16.1/{server}/labels: get: operationId: listLabels description: | Lists available labels in the system. The resources of this list are summaries of labels in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of labels in the system. schema: type: array items: $ref: "#/definitions/LabelsCommand" post: operationId: addLabel description: | Creates a new label specification, like the `p4 label` command. parameters: - $ref: '#/parameters/server' - name: label in: body description: The label spec required: true schema: $ref: "#/definitions/LabelCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/labels/{label}: get: operationId: getLabel description: | Returns the label spec details of the particular label. parameters: - $ref: '#/parameters/server' - name: label in: path description: The label ID required: true type: string responses: 200: description: Label spec details schema: $ref: "#/definitions/LabelCommand" patch: operationId: updateLabel description: | Update label specifications, similar to the `p4 label` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: label in: path description: The label ID required: true type: string - name: labelCommand in: body required: true description: Fields of the label to update schema: $ref: "#/definitions/LabelCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteLabel description: | Removes the label specification, similar to the `p4 label -d` command. parameters: - $ref: '#/parameters/server' - name: label in: path description: The label ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Paths #-----------a---------------------------------------------------------- /api/p4/v16.1/{server}/paths: get: operationId: listPaths description: | Lists depots, files, and directories in the system. This combines the output of the `p4 depots`, `p4 dirs`, and `p4 files` commands, depending upon your path. parameters: - $ref: '#/parameters/server' - name: path in: query description: | The path "under a depot" to query under, e.g., `//depot/main`. This will list the directories and files underneath that path. required: false type: string responses: 200: description: Array of depots. schema: type: array items: $ref: '#/definitions/Location' #--------------------------------------------------------------------- # Login #--------------------------------------------------------------------- /api/p4/v16.1/{server}/login: post: operationId: serverLogin description: | Logs into a Helix Versioning Engine (p4d) server. parameters: - $ref: '#/parameters/server' responses: 200: description: Object with ticket to use for Basic auth password. schema: $ref: '#/definitions/LoginResponse' security: [] #--------------------------------------------------------------------- # Protections #--------------------------------------------------------------------- /api/p4/v16.1/{server}/protections: get: operationId: listProtections description: | Returns a list of available protections in the system. The elements of this list are rows of the system's protections table. This method requires superuser access. See the output of http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_protect.html[`p4 protect`] for more information. parameters: - $ref: '#/parameters/server' responses: 200: description: Object including list of protections entries schema: $ref: '#/definitions/Protections' put: operationId: updateProtections description: | Updates the protections table. This method requires superuser access. parameters: - $ref: '#/parameters/server' - name: protections in: body description: The new protections table required: true schema: $ref: '#/definitions/Protections' responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Servers #--------------------------------------------------------------------- /api/p4/v16.1/{server}/servers: get: operationId: listServers description: | Lists available servers in the system. The resources of this list are summaries of servers in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of servers in the system. schema: type: array items: $ref: "#/definitions/ServersCommand" post: operationId: addServer description: | Creates a new server specification, like the `p4 server` command. parameters: - $ref: '#/parameters/server' - name: serverCommand in: body description: The server spec required: true schema: $ref: "#/definitions/ServerCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/servers/{serverId}: get: operationId: getServer description: | Returns the server spec details of the particular server. parameters: - $ref: '#/parameters/server' - name: serverId in: path description: The server ID of the server spec required: true type: string responses: 200: description: Server spec details schema: $ref: "#/definitions/ServerCommand" patch: operationId: updateServer description: | Update server specifications, similar to the `p4 server` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: serverId in: path description: The server ID required: true type: string - name: serverCommand in: body required: true description: Fields of the server to update schema: $ref: "#/definitions/ServerCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteServer description: | Removes the server specification, similar to the `p4 server -d` command. parameters: - $ref: '#/parameters/server' - name: serverId in: path description: The server ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Streams #--------------------------------------------------------------------- /api/p4/v16.1/{server}/streams: get: operationId: listStreams description: | Lists available streams in the system. The resources of this list are summaries of streams in the system. parameters: - $ref: '#/parameters/server' responses: 200: description: Summaries of streams in the system. schema: type: array items: $ref: "#/definitions/StreamsCommand" post: operationId: addStream description: | Creates a new stream specification, like the `p4 stream` command. parameters: - $ref: '#/parameters/server' - name: body in: body description: The stream spec required: true schema: $ref: "#/definitions/StreamCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/streams/stream: get: operationId: getStream description: | Returns the stream spec details of the particular stream. parameters: - $ref: '#/parameters/server' - name: stream in: query description: The stream ID required: true type: string responses: 200: description: Stream spec details schema: $ref: "#/definitions/StreamCommand" patch: operationId: updateStream description: | Update stream specifications, similar to the `p4 stream` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: stream in: query description: The stream ID required: true type: string - name: body in: body required: true description: Fields of the stream to update schema: $ref: "#/definitions/StreamCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteStream description: | Removes the stream specification, similar to the `p4 stream -d` command. parameters: - $ref: '#/parameters/server' - name: stream in: query description: The stream ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # Triggers #--------------------------------------------------------------------- /api/p4/v16.1/{server}/triggers: get: operationId: listTriggers description: | Returns a list of available triggers in the system. The elements of this list are rows of the system's triggers table. This method requires superuser access. parameters: - $ref: '#/parameters/server' responses: 200: description: List of triggers entries schema: $ref: '#/definitions/Triggers' put: operationId: updateTriggers description: | Updates the triggers table. This method requires superuser access. parameters: - $ref: '#/parameters/server' - name: triggers in: body description: The new triggers table required: true schema: $ref: '#/definitions/Triggers' responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' #--------------------------------------------------------------------- # P4 Users #--------------------------------------------------------------------- /api/p4/v16.1/{server}/users: get: operationId: listUsers description: | Lists available users in the system. The resources of this list are summaries of users in the system. parameters: - $ref: '#/parameters/server' - name: includeService in: query description: If true, shows service users in the list. required: false type: boolean - name: max in: query description: Cap the number of users reported to this amount. required: false type: integer responses: 200: description: Summaries of users in the system. schema: type: array items: $ref: "#/definitions/UsersCommand" post: operationId: addUser description: | Creates a new user specification, like the `p4 user` command. parameters: - $ref: '#/parameters/server' - name: body in: body description: The user spec required: true schema: $ref: "#/definitions/UserCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' /api/p4/v16.1/{server}/users/{user}: get: operationId: getUser description: | Returns the user spec details of the particular user. parameters: - $ref: '#/parameters/server' - name: user in: path description: The user ID required: true type: string responses: 200: description: User spec details schema: $ref: "#/definitions/UserCommand" patch: operationId: updateUser description: | Update user specifications, similar to the `p4 user` command. Only the specified parameters in the body will be changed. parameters: - $ref: '#/parameters/server' - name: user in: path description: The user ID required: true type: string - name: body in: body required: true description: Fields of the user to update schema: $ref: "#/definitions/UserCommand" responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' delete: operationId: deleteUser description: | Removes the user specification, similar to the `p4 user -d` command. parameters: - $ref: '#/parameters/server' - name: user in: path description: The user ID required: true type: string responses: 200: description: Server messages. schema: $ref: '#/definitions/CommandResponse' # NOTE: All responses really should include additionalProperties, since you'll # never be able to completely type most data coming from the server. Just "likely" # data. definitions: BranchCommand: type: object description: | Models the output of a `p4 branch` command. For more information see the [command reference](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_branch.html). properties: branch: type: string description: The branch name, as provided on the command line. owner: type: string description: | The owner of the branch mapping. By default, this will be set to the user who created the branch. This field is unimportant unless the Option: field value is locked. access: type: string format: date-time description: The date the branch mapping was last accessed. update: type: string format: date-time description: The date the branch mapping was last changed. options: type: string enum: ["unlocked", "locked"] description: | Either `unlocked` (the default) or `locked`. If `locked`, only the `Owner:` can modify the branch mapping, and the mapping can't be deleted until it is `unlocked`. description: type: "string" description: A short description of the branch's purpose. view: type: "array" items: type: "string" description: | A set of mappings from one set of files in the depot (the source files) to another set of files in the depot (the target files). The view maps from one location in the depot to another; it can't refer to a client workspace. For example, the branch view `//depot/main/... //depot/r2.1/...` maps all the files under `//depot/main` to `//depot/r2.1`. BranchesCommand: type: object description: | A reference to a branch mapping known to the system. properties: branch: type: string description: The branch name, as provided on the command line. owner: type: string description: | The owner of the branch mapping. By default, this will be set to the user who created the branch. This field is unimportant unless the Option: field value is locked. access: type: string format: date-time description: The date the branch mapping was last accessed. update: type: string format: date-time description: The date the branch mapping was last changed. options: type: string enum: ["unlocked", "locked"] description: | Either `unlocked` (the default) or `locked`. If `locked`, only the `Owner:` can modify the branch mapping, and the mapping can't be deleted until it is `unlocked`. description: type: "string" description: A short description of the branch's purpose. ChangeCommand: type: object description: | A changelist specification. For more information see the [command reference](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_change.html). properties: change: type: string description: | Contains the changelist number if editing an existing changelist, or `new` if creating a new changelist. client: type: string description: Name of current client workspace date: type: string format: date-time description: Date the changelist was last modified. user: type: string description: | Name of the change owner. The owner of an empty pending changelist (that is, a pending changelist without any files in it) can transfer ownership of the changelist to another existing user either by editing this field, or by using the -U user option. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. status: type: string enum: ["pending", "shelved", "submitted", "new"] description: | `pending`, `shelved`, `submitted`, or `new`. Not editable by the user. The status is `new` when the changelist is created, `pending` when it has been created but has not yet been submitted to the depot, `shelved` when its contents are shelved, and `submitted` when its contents have been stored in the depot. description: type: string description: | Textual description of changelist. If you do not have access to a restricted changelist, the description is replaced with a "no permission" message. jobs: type: array description: | A list of jobs that are fixed by this changelist. items: type: string type: type: string enum: ["restricted", "public"] description: | Type of change: `restricted` or `public`. The Type: field can be used to hide the change or its description from users. A shelved or committed change (as denoted in the Status: field) that is restricted is accessible only to users who own the change or have list permission to at least one file in the change. Public changes are displayed without restrictions. By default, changelists are public. A Perforce superuser can set the default changelist type (for changelists created after the configurable is set) by setting the defaultChangeType configurable. files: type: array items: type: string description: | The list of files submitted in this changelist. importedBy: type: string description: | Displays the name of the user who ran the p4 fetch, p4 push, or p4 unzip command that imported this change into the server. This field is primarily useful for distributed versioning (DVCS) scenarios, in which changelists are copied from one server to another, and help you correlate the changelist’s basic identity as it is copied. In such configurations, Perforce recommends using the submit.identity configurable to enable automatic generation of changelist identities by the p4 submit. identify: type: string description: | Contains a label which uniquely identifies this changelist across all servers where it has been fetched, pushed, or unzipped. This field is primarily useful for distributed versioning (DVCS) scenarios, in which changelists are copied from one server to another, and help you correlate the changelist’s basic identity as it is copied. In such configurations, Perforce recommends using the submit.identity configurable to enable automatic generation of changelist identities by the p4 submit. ChangesCommand: type: object properties: change: type: string description: The changelist ID date: type: string format: date-time description: Last modification time of the changelist user: type: string description: The owner of the changelist client: type: string description: Name of current client workspace. status: type: string enum: ["pending", "shelved", "submitted", "new"] description: | `pending`, `shelved`, `submitted`, or `new`. Not editable by the user. The status is `new` when the changelist is created, `pending` when it has been created but has not yet been submitted to the depot, `shelved` when its contents are shelved, and `submitted` when its contents have been stored in the depot. type: type: string enum: ["restricted", "public"] description: | Type of change: `restricted` or `public`. The Type: field can be used to hide the change or its description from users. A shelved or committed change (as denoted in the Status: field) that is restricted is accessible only to users who own the change or have list permission to at least one file in the change. Public changes are displayed without restrictions. By default, changelists are public. A Perforce superuser can set the default changelist type (for changelists created after the configurable is set) by setting the defaultChangeType configurable. path: type: string description: Depot paths affected by this changelist description: type: string description: | Textual description of changelist. If you do not have access to a restricted changelist, the description is replaced with a "no permission" message. ChangelistRequest: type: object properties: description: type: string stream: type: string description: Optional stream ID to use in case you want to edit files in a stream. actions: type: array items: $ref: '#/definitions/ChangelistAction' ChangelistAction: type: object properties: depotFile: type: string description: The target file path to edit. fromDepotFile: type: string description: For "branch" or "move" actions, this indicates the source file location. actionType: type: string description: One of "upload", "branch", "move", or "delete" content: type: string description: Base64-encoded content requireVersion: type: integer description: If set, we will only operate if this is the current version of the file. default: -1 ClientCommand: type: object description: | The client workspace specification and its view. For more information see the [command reference](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html). properties: client: type: string description: | The client workspace name, as specified in the `P4CLIENT` environment variable or its equivalents. owner: type: string description: | The name of the user who owns the workspace. The default is the user who created the workspace. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. update: type: string format: date-time description: The time the workspace specification was last modified. access: type: string format: date-time description: | The date and time that the workspace was last used in any way. (Note: Reloading a workspace with p4 reload does not affect the access time.) host: type: string description: | The name of the workstation on which this workspace resides. If included, operations on this client workspace can be run only from this host. If not set, access is allowed from any host. The hostname must be provided exactly as it appears in the output of p4 info when run from that host. This field is meant to prevent accidental misuse of client workspaces on the wrong machine. Providing a host name does not guarantee security, because the actual value of the host name can be overridden with the -H option to any p4 command, or with the P4HOST environment variable. For a similar mechanism that does provide security, use the IP address restriction feature of p4 protect. description: type: string description: | A textual description of the workspace. The default text is Created by owner. root: type: string description: | The directory (on the local host) relative to which all the files in the `View:` are specified. The default is the current working directory. The path must be specified in local file system syntax. If you change this setting, you must physically relocate any files that currently reside there. On Windows client machines, you can specify the root as null to enable you to map files to multiple drives. altRoots: type: array items: type: string description: | Up to two optional alternate client workspace roots. Perforce applications use the first of the main and alternate roots that match the application’s current working directory. Use the p4 info command to display the root being used. This enables users to use the same Perforce client workspace specification on multiple platforms, even those with different directory naming conventions. If you are using multiple or alternate workspace roots (the AltRoots: field), you can always tell which root is in effect by looking at the Client root: reported by p4 info. If you are using a Windows directory in any of your workspace roots, you must specify the Windows directory as your main workspace root and specify your other workspace roots in the AltRoots: field. options: type: string description: | A set of seven switches that control particular workspace options. See [Usage Notes](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html#p4_client.usage) for a listing of these options. submitOptions: type: string description: | Options to govern the default behavior of p4 submit. * submitunchanged + All open files (with or without changes) are submitted to the depot. This is the default behavior of Perforce. * submitunchanged+reopen + All open files (with or without changes) are submitted to the depot, and all files are automatically reopened in the default changelist. * revertunchanged + Only those files with content, type, or resolved changes are submitted to the depot. Unchanged files are reverted. * revertunchanged+reopen + Only those files with content, type, or resolved changes are submitted to the depot and reopened in the default changelist. Unchanged files are reverted and not reopened in the default changelist. * leaveunchanged + Only those files with content, type, or resolved changes are submitted to the depot. Any unchanged files are moved to the default changelist. * leaveunchanged+reopen + Only those files with content, type, or resolved changes are submitted to the depot. Unchanged files are moved to the default changelist, and changed files are reopened in the default changelist. This option is similar to submitunchanged+reopen, except that no unchanged files are submitted to the depot. lineEnd: type: string description: | Configure carriage-return/linefeed (CR/LF) conversion. See [Usage Notes](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html#p4_client.usage) for a listing of these options. stream: type: string description: | Associates the workspace with the specified stream. Perforce generates the view for stream-associated workspaces: you cannot modify it manually. streamAtChange: type: string description: | A changelist number that sets a back-in-time view of a stream. When StreamAtChange is set, running p4 sync (when called with no arguments) updates the workspace to files at this changelist revision, instead of the head revision. You cannot submit changes (p4 submit returns an error) when StreamAtChange is set, because the workspace view no longer reflects the current stream inheritance. This field is ignored unless the Stream field is also set to a valid stream. serverID: type: string description: | If set, restricts usage of the workspace to the named server. If unset, use is allowed on master server and on any replicas of the master other than Edge servers. view: type: array items: type: string description: | Specifies the mappings between files in the depot and files in the workspace. A new view takes effect on the next p4 sync operation. changeView: type: array items: type: string description: | Restricts access to depot paths to a particular point in time. Files specified for the ChangeView field are read-only: they may be opened but not submitted. For example: `//depot/path/...@1000` Revisions of the files in the specified path will not be visible if they were submitted after the specified changelist number. Files matching a ChangeView path may not be submitted. type: type: string description: | By default clients are writeable. Specify readonly for short lived clients used in build automation scripts. Such clients cannot edit or submit files, but this should not be an issue in build scripts. Using writeable clients in build automation scripts can lead to db.have table fragmentation, which is used to track what files a client has synced. If you are experiencing such issues, use a read-only client instead. A readonly client is assigned its own personal db.have database table. The location of this table must first be specified by an administrator with the client.readonly.dir configurable. ClientsCommand: type: object properties: client: type: string description: | The client workspace name, as specified in the `P4CLIENT` environment variable or its equivalents. owner: type: string description: | The name of the user who owns the workspace. The default is the user who created the workspace. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. update: type: string format: date-time description: The time the workspace specification was last modified. access: type: string format: date-time description: | The date and time that the workspace was last used in any way. (Note: Reloading a workspace with p4 reload does not affect the access time.) host: type: string description: | The name of the workstation on which this workspace resides. If included, operations on this client workspace can be run only from this host. If not set, access is allowed from any host. The hostname must be provided exactly as it appears in the output of p4 info when run from that host. This field is meant to prevent accidental misuse of client workspaces on the wrong machine. Providing a host name does not guarantee security, because the actual value of the host name can be overridden with the -H option to any p4 command, or with the P4HOST environment variable. For a similar mechanism that does provide security, use the IP address restriction feature of p4 protect. description: type: string description: | A textual description of the workspace. The default text is Created by owner. root: type: string description: | The directory (on the local host) relative to which all the files in the `View:` are specified. The default is the current working directory. The path must be specified in local file system syntax. If you change this setting, you must physically relocate any files that currently reside there. On Windows client machines, you can specify the root as null to enable you to map files to multiple drives. additionalProperties: type: type: string description: | By default clients are writeable. Specify readonly for short lived clients used in build automation scripts. Such clients cannot edit or submit files, but this should not be an issue in build scripts. Using writeable clients in build automation scripts can lead to db.have table fragmentation, which is used to track what files a client has synced. If you are experiencing such issues, use a read-only client instead. A readonly client is assigned its own personal db.have database table. The location of this table must first be specified by an administrator with the client.readonly.dir configurable. options: type: string description: | A set of seven switches that control particular workspace options. See [Usage Notes](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html#p4_client.usage) for a listing of these options. submitOptions: type: string description: | Options to govern the default behavior of p4 submit. * submitunchanged + All open files (with or without changes) are submitted to the depot. This is the default behavior of Perforce. * submitunchanged+reopen + All open files (with or without changes) are submitted to the depot, and all files are automatically reopened in the default changelist. * revertunchanged + Only those files with content, type, or resolved changes are submitted to the depot. Unchanged files are reverted. * revertunchanged+reopen + Only those files with content, type, or resolved changes are submitted to the depot and reopened in the default changelist. Unchanged files are reverted and not reopened in the default changelist. * leaveunchanged + Only those files with content, type, or resolved changes are submitted to the depot. Any unchanged files are moved to the default changelist. * leaveunchanged+reopen + Only those files with content, type, or resolved changes are submitted to the depot. Unchanged files are moved to the default changelist, and changed files are reopened in the default changelist. This option is similar to submitunchanged+reopen, except that no unchanged files are submitted to the depot. lineEnd: type: string description: | Configure carriage-return/linefeed (CR/LF) conversion. See [Usage Notes](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html#p4_client.usage) for a listing of these options. stream: type: string description: | Associates the workspace with the specified stream. Perforce generates the view for stream-associated workspaces: you cannot modify it manually. CommandResponse: type: object description: | A generic container for responses from the p4d server that we have yet to completely classify. properties: results: type: array description: A collection of maps that have various values set by p4d. items: type: object additionalProperties: type: object CommandRequest: type: object description: | A single map typically defines input to generic command methods. properties: object: description: Don't use this. It's a kludge around a bug in the Java client code generator type: object additionalProperties: type: object Counter: type: object description: A persistent variable in the server. properties: counter: type: string description: The variable name value: type: string description: | The variable value. Many variables are numerical in nature, which allow you to do atomic increment operations in method calls instead of having to fetch, increment, and save. DepotCommand: type: object description: | The depot specification, which is the shared repository Perforce stores files in. properties: depot: type: string description: | The depot name. owner: type: string description: | The user who owns the depot. By default, this is the user who created the depot. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. description: type: string description: | A short description of the depot’s purpose. Optional. type: type: string description: | `local`, `remote`, `spec`, `stream`, `unload`, `archive` or `tangent`. A local depot is writable, and is the default depot type. Files reside in the server's root directory and are managed directly by the server. A stream depot is also writable, but contains streams, a type of branch that includes hierarchy and policy. A remote depot references files that reside on other servers, and cannot be written to. The spec depot, if present, automatically archives edited forms. The unload depot, if present, holds infrequently-used metadata (about old client workspaces and labels) that has been unloaded with the p4 unload command. An archive depot is used in conjunction with the p4 archive and p4 restore commands to facilitate offline (or near-line) storage of infrequently-accessed revisions, typically large binaries. A tangent depot defines a read-only location that holds tangents created by the p4 fetch -t command. The tangent depot named tangent is automatically created by p4 fetch -t if one does not already exist. address: type: string description: | If the `Type:` is `remote`, the address should be the P4PORT address of the remote server. If the `Type:` is local or spec, this field is ignored. suffix: type: string description: | If the Type: is spec, this field holds an optional suffix for generated paths to objects in the spec depot. The default suffix is .p4s. You do not need a suffix to use the spec depot, but supplying a file extension to your Perforce server’s versioned specs enables users of GUI client software to associate Perforce specifications with a preferred text editor. If the Type: is local or remote, this field is ignored. streamDepth: type: string description: | For stream depots, the optional depth to be used for stream paths in the depot, where depth specifies the number of slashes following the depot name of a stream. ] This field is used when streams are being created. The default is 1, matching the traditional stream name. You cannot update this value once streams or archive data exist in a depot. map: type: string description: | If the Type: is local, spec, or archive, set the map to point to the relative location of the depot subdirectory. The map must contain the `...` wildcard; for example, a local depot new might have a Map: of `new/...`. If the Type: is remote, set the map to point to a location in the remote depot's physical namespace, for example, `//depot/new/rel2/...`. This directory will be the root of the local representation of the remote depot. specMap: type: array items: type: string description: | For spec depots, an optional description of which specs should be saved, expressed as a view. DepotsCommand: type: object description: | A summary of depots in the system, with information provided by the `p4 depots` command. properties: depot: type: string description: | The depot name. map: type: string description: | If the Type: is local, spec, or archive, set the map to point to the relative location of the depot subdirectory. The map must contain the `...` wildcard; for example, a local depot new might have a Map: of `new/...`. If the Type: is remote, set the map to point to a location in the remote depot's physical namespace, for example, `//depot/new/rel2/...`. This directory will be the root of the local representation of the remote depot. type: type: string description: | `local`, `remote`, `spec`, `stream`, `unload`, `archive` or `tangent`. A local depot is writable, and is the default depot type. Files reside in the server's root directory and are managed directly by the server. A stream depot is also writable, but contains streams, a type of branch that includes hierarchy and policy. A remote depot references files that reside on other servers, and cannot be written to. The spec depot, if present, automatically archives edited forms. The unload depot, if present, holds infrequently-used metadata (about old client workspaces and labels) that has been unloaded with the p4 unload command. An archive depot is used in conjunction with the p4 archive and p4 restore commands to facilitate offline (or near-line) storage of infrequently-accessed revisions, typically large binaries. A tangent depot defines a read-only location that holds tangents created by the p4 fetch -t command. The tangent depot named tangent is automatically created by p4 fetch -t if one does not already exist. streamDepth: type: string description: | For stream depots, the optional depth to be used for stream paths in the depot, where depth specifies the number of slashes following the depot name of a stream. ] This field is used when streams are being created. The default is 1, matching the traditional stream name. You cannot update this value once streams or archive data exist in a depot. description: type: string description: | A short description of the depot’s purpose. Optional. DirsCommand: type: object properties: dir: type: string FilesCommand: type: object properties: depotFile: type: string revision: type: string change: type: string action: type: string time: type: string format: date-time type: type: string FixesCommand: type: object description: | A list jobs with fixes and the changelists that fix them. properties: job: type: string change: type: string date: type: string format: date-time user: type: string client: type: string status: type: string FstatCommand: type: object description: | Detailed information about each file, as provided by the `p4 fstat` command. properties: depotFile: type: string description: | Depot path to file. For files containing special characters, the filename is displayed containing the ASCII expression of the character’s hexadecimal value. movedFile: type: string description: | Name in depot of moved to/from file. shelved: type: string description: Set to `shelved` if file is shelved. headAction: type: string description: | Action taken at head revision, if in depot. One of: add, edit, delete, branch, move/add, move/delete, integrate, import, purge, or archive. headChange: type: string description: | Head revision changelist number, if in depot. headRev: type: string description: | Head revision number, if in depot. headType: type: string description: | Head revision type, if in depot. headCharset: type: string description: | Head charset, for unicode files. headTime: type: string format: date-time description: | Head revision changelist time, if in depot. Time is measured in seconds since 00:00:00 UTC, January 1, 1970. headModTime: type: string format: date-time description: | Head revision modification time (the time that the file was last modified on the client before submit), if in depot. movedRev: type: string description: | Head revision of moved file. digest: type: string description: | MD5 digest of a file. fileSize: type: string description: | File length in bytes. actionOwner: type: string description: | User who opened the file, if open. resolved: type: string description: | The number, if any, of resovled integration records. unresolved: type: string description: | The number, if any, of unresolved integration records. reresolvable: type: string description: | The number, if any, of re-resolvable integration records. otherOpens: type: array items: type: string description: | For each user with the file open, the workspace and user with the open file. otherLocks: type: array items: type: string description: | For each user with the file locked, the workspace and user holding the lock. otherActions: type: array items: type: string description: | For each user with the file open, the action taken. otherChanges: type: array items: type: string description: | The changelist number with this file open. resolveActions: type: array items: type: string description: | Pending integration action. resolveBaseFiles: type: array items: type: string description: | Pending base files. resolveBaseRevs: type: array items: type: string description: | Pending base revision numbers. resolveFromFiles: type: array items: type: string description: | Pending from files. resolveStartFromRevs: type: array items: type: string description: | Pending starting revisions. resolveEndFromRevs: type: array items: type: string description: | Pending ending revisions. GroupCommand: type: object description: | Add or delete users from a group, or set the maxresults, maxscanrows, maxlocktime, and timeout limits for the members of a group. properties: group: type: string description: | The name of the group, as entered on the command line. maxResults: type: string description: | The maximum number of results that members of this group can access from the service from a single command. The default value is `unset`. maxScanRows: type: string description: | The maximum number of rows that members of this group can scan from the service from a single command. The default value is `unset`. maxLockTime: type: string description: | The maximum length of time (in milliseconds) that any one operation can lock any database table when scanning data. The default value is `unset`. maxOpenFiles: type: string description: | The maximum number of files that a member of a group can open using a single command. timeout: type: string description: | The duration (in seconds) of the validity of a session ticket created by p4 login. The default value is 43,200 seconds (12 hours). To create a ticket that does not expire, set the Timeout: field to `unlimited`. passwordTimeout: type: string description: | The length of time (in seconds) for which passwords for users in this group remain valid. To disable password aging, use a value of unset. ldapConfig: type: string description: | The LDAP configuration to use when populating the group’s user list from an LDAP query. ldapSearchQuery: type: string description: | The LDAP query used to identify the members of the group. ldapUserAttribute: type: string description: | The LDAP attribute that represents the user’s username. subgroups: type: array items: type: string description: | Names of other Perforce groups. To add all users in a previously defined group to the group you’re presently working with, include the group name in the Subgroups: field of the p4 group form. Note that user and group names occupy separate namespaces, and thus, groups and users can have the same names. Every member of any previously defined group you list in the Subgroups: field will be a member of the group you’re now defining. owners: type: array items: type: string description: | Names of other Perforce users. Group owners without super access are permitted to administer this group, provided that they use the -a option. Group owners are not necessarily members of a group; if a group owner is to be a member of the group, the userid must also be added to the Users: field. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. users: type: array items: type: string description: | The Perforce usernames of the group members. GroupsCommand: type: object description: | A list of entries that can show the layout how users are associated with the different groups in the system. properties: user: type: string group: type: string isSubGroup: type: string isOwner: type: string isUser: type: string maxResults: type: string maxScanRows: type: string maxLockTime: type: string maxOpenFiles: type: string timeout: type: string passTimeout: type: string JobCommand: type: object description: | A defect, enhancement request, or other job specification. The actual fields in a job can be edited by a superuser in your system. The default set of fields in a system are Job, Status, User, Date, and Description. properties: Job: type: string description: The job name. additionalProperties: type: object JobsCommand: type: object description: | A summary of jobs in the system. The actual fields in a job can be edited by a superuser in your system. The default set of fields in a system are Job, Status, User, Date, and Description. Fields in the output of this command may be missing if the superuser removed User, Status, Date, or Description. properties: Job: type: string description: The job name. additionalProperties: type: object LabelsCommand: type: object properties: label: type: string description: | The label name. update: type: string format: date-time description: | The date the label specification was last modified. access: type: string format: date-time description: | The date and time the label was last accessed, either by running p4 labelsync on the label, or by otherwise referring to a file with the label revision specifier @label. (Note: Reloading a label with p4 reload does not affect the access time.) owner: type: string description: | The label’s owner. By default, the user who created the label. Only the owner of a label can update which files are tagged with the label. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. options: type: string description: | Options to control behavior and storage location of labels. - locked or unlocked: If the label is locked, the list of files tagged with the label cannot be changed with p4 labelsync. - autoreload or noautoreload. For static labels, if noautoreload is set, the label is stored in db.label, and if autoreload is set, it is stored in the unload depot. This option is ignored for automatic labels. Storing labels in the unload depot can improve performance on sites that make extremely heavy use of labels. description: type: string description: | An optional description of the label’s purpose. LabelCommand: type: object description: | A label specification. Labels can be either automatic or static. Automatic labels refer to the revisions provided in the View: and Revision: fields. Static labels refer only to those specific revisions tagged by the label by means of either the p4 labelsync or p4 tag commands. properties: label: type: string description: | The label name. owner: type: string description: | The label’s owner. By default, the user who created the label. Only the owner of a label can update which files are tagged with the label. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. update: type: string format: date-time description: | The date the label specification was last modified. access: type: string format: date-time description: | The date and time the label was last accessed, either by running p4 labelsync on the label, or by otherwise referring to a file with the label revision specifier @label. (Note: Reloading a label with p4 reload does not affect the access time.) description: type: string description: | An optional description of the label’s purpose. options: type: string description: | Options to control behavior and storage location of labels. - locked or unlocked: If the label is locked, the list of files tagged with the label cannot be changed with p4 labelsync. - autoreload or noautoreload. For static labels, if noautoreload is set, the label is stored in db.label, and if autoreload is set, it is stored in the unload depot. This option is ignored for automatic labels. Storing labels in the unload depot can improve performance on sites that make extremely heavy use of labels. revision: type: string description: | An optional revision specification for an automatic label. If you use the # character to specify a revision number, you must use quotes around it in order to ensure that the # is parsed as a revision specifier, and not as a comment field in the form. view: type: array items: type: string description: | A list of depot files that can be tagged with this label. No files are actually tagged until `p4 labelsync` is invoked. Unlike client views or branch views, which map one set of files to another, label views consist of a simple list of depot files. serverID: type: string description: | If set, restricts usage of the label to the named server. If unset, this label may be used on any server. Location: type: object description: | A consolidated mechanism for identifying something that generally has a path in the system. Each location references either a depot, a dir, or a file. properties: depotPath: type: string description: An absolute depot path specification. depot: $ref: '#/definitions/DepotsCommand' dir: $ref: '#/definitions/DirsCommand' file: $ref: '#/definitions/FilesCommand' fstat: $ref: '#/definitions/FstatCommand' content: type: string description: | If this location indicates a single file, this can be set with the Base64-encoded content of the file. LoginResponse: type: object description: | Either of our login methods return a ticket, which is then used as a password in a basic authentication scheme. When this is returned from the explicit p4d login, this is a host unlocked ticket, acceptable for using with a local client. properties: ticket: type: string Protections: type: object description: | Displays the information stored in the `p4 protect` command. properties: protections: type: array description: | Each item in the protections array is a line in the protections table, and is split into five columns. 1. Access level or mode. One of the access levels list, read, open, write, admin, super, review; or one of the rights =read, =open, =write, and =branch, 2. Either `user` or `group`, to indicate what's identified by this entry. 3. The group name or user name. To grant permission to all users, use a wildcard with just an asterix symbol. 4. The IP address of the client host. 5. The depot file path, which can contain wildcards. To exclude this mapping from the permission set, use a dash `-` as the first character of this value. IPv6 addresses and IPv4 addresses are also supported. You can use the * wildcard to refer to all IP addresses, but only when you are not using CIDR notation. If you use the * wildcard with an IPv6 address, you must enclose the entire IPv6 address in square brackets. For example, [2001:db8:1:2:*] is equivalent to [2001:db8:1:2::]/64. Best practice is to use CIDR notation, surround IPv6 addresses with brackets, and to avoid the * wildcard. How the system forms host addresses depends on the setting of the dm.proxy.protects variable. By default, this variable is set to 1. This means that if the client host uses some intermediary (proxy, broker, replica) to access the server, the proxy- prefix is prepended to the client host address to indicate that the connection is not direct. If you specify proxy-* for the Host field, that will affect all connections made via proxies, brokers, and replicas. A value like proxy-10.0.0.5 identifies a client machine with an IP address of 10.0.0.5 that is connected to the server through an intermediary. Setting the dm.proxy.protects variable to 0, removes the proxy- prefix and allows you to write a single set of protection entries that apply both to directly-connected clients as well as to those that connect via an intermediary. This is more convenient but less secure if it matters that a connection is made using an intermediary. If you use this setting, all intermediaries must be at release 2012.1 or higher. items: type: string ServersCommand: type: object properties: serverID: type: string description: | A unique identifier for this server. This must match the contents of the server’s `server.id` file as defined by the p4 serverid command. If the server type is identifier, the server id specifies the name of the cluster. type: type: string enum: ["server", "proxy", "broker", "identifier", "admin"] description: | Server executable type. One of the following: `server`, `proxy`, `broker`, `identifier`, `admin`. Each type may offer one or more services, defined in the `services` property. services: type: string description: | The `server` type server provides the following services: - standard - a standard Perforce server - replica - a read-only replica server - commit-server - central server in distributed installation - edge-server - node in distributed installation - forwarding-replica - a replica configured to forward commands that involve database writes to a master server - build-server - a replica that supports build automation and build farm integration - P4AUTH - a server that provides authentication - P4CHANGE - a server that provides change numbering - depot-master - commit-server with automated failover - depot-standby - standby replica of the depot-master - workspace-server - node in a cluster installation - standby - read-only replica server that uses p4 journalcopy - forwarding-standby - forwarding replica server that uses p4 journalcopy The `proxy` type server provides a p4p caching proxy. The `broker` type server provides the following services: - broker - a p4broker process - workspace-router - routing broker for a cluster The services field for the `identifier` type server specifies the existence of the cluster, and has the value `cluster`. The name of the cluster is then drawn from the ServerID field. The `admin` type server provides the following services: - hxca-server - the admin server for a Helix cluster. - zookeeper-server - ZooKeeper server for a cluster name: type: string description: | The P4NAME associated with this server. You can leave this blank or you can set it to the same value as the serverid. address: type: string description: | The P4PORT used by this server. description: type: string description: | An optional description for this server. user: type: string description: | The service user name used by the server. ServerCommand: type: object description: | The Perforce server specification describes the high-level configuration and intended usage of a Perforce server. For installations with only one Perforce server, the server specification is optional. properties: serverID: type: string description: | A unique identifier for this server. This must match the contents of the server’s `server.id` file as defined by the p4 serverid command. If the server type is identifier, the server id specifies the name of the cluster. type: type: string enum: ["server", "proxy", "broker", "identifier", "admin"] description: | Server executable type. One of the following: `server`, `proxy`, `broker`, `identifier`, `admin`. Each type may offer one or more services, defined in the `services` property. services: type: string description: | The `server` type server provides the following services: - standard - a standard Perforce server - replica - a read-only replica server - commit-server - central server in distributed installation - edge-server - node in distributed installation - forwarding-replica - a replica configured to forward commands that involve database writes to a master server - build-server - a replica that supports build automation and build farm integration - P4AUTH - a server that provides authentication - P4CHANGE - a server that provides change numbering - depot-master - commit-server with automated failover - depot-standby - standby replica of the depot-master - workspace-server - node in a cluster installation - standby - read-only replica server that uses p4 journalcopy - forwarding-standby - forwarding replica server that uses p4 journalcopy The `proxy` type server provides a p4p caching proxy. The `broker` type server provides the following services: - broker - a p4broker process - workspace-router - routing broker for a cluster The services field for the `identifier` type server specifies the existence of the cluster, and has the value `cluster`. The name of the cluster is then drawn from the ServerID field. The `admin` type server provides the following services: - hxca-server - the admin server for a Helix cluster. - zookeeper-server - ZooKeeper server for a cluster name: type: string description: | The P4NAME associated with this server. You can leave this blank or you can set it to the same value as the serverid. address: type: string description: | The P4PORT used by this server. externalAddress: type: string description: | For an edge server, this optional field specifies the external address used for connections to a commit server. This field must be set for the edge server to enable parallel submits in a federated environment. description: type: string description: | An optional description for this server. user: type: string description: | The service user name used by the server. clientDataFilter: type: string description: | For a replica server, this optional field can contain one or more patterns describing how active client workspace metadata is to be filtered. Active client workspace data includes have lists, working records, and pending resolves. To include client data, use the syntax: `//client-pattern/...` To exclude client data, use the syntax: `-//client-pattern/...` All patterns are specified in client syntax. revisionDataFilter: type: string description: | For a replica server, this optional field can contain one or more patterns describing how submitted revision metadata is to be filtered. Submitted revision data includes revision records, integration records, label contents, and the files listed in submitted changelists. To include depot data, use the syntax: //depot/pattern/... To exclude depot data, use the syntax: -//depot/pattern/... All patterns are specified in depot syntax. archiveDataFilter: type: string description: | For a replica server, this optional field can contain one or more patterns describing the policy for automatically scheduling the replication of file content. If this field is present, only those files described by the pattern are automatically transferred to the replica; other files are not transferred until they are referenced by a replica command that needs the file content. Files specified in the ArchiveDataFilter: field are transferred to the replica regardless of whether any users of the replica have made requests for their content. To automatically transfer files on submit, use the syntax: `//depot/pattern/...` To exclude files from automatic transfer, use the syntax: `-//depot/pattern/...` All patterns are specified in depot syntax. distributedConfig: type: string description: | For an edge or commit server, this optional field, which is displayed only when you use the -l or -c option, shows configuration settings for this server. `-l` flag shows the current configuration. `-c-` flag shows current configuration values, recommended default values for fields that are not set, or unset for fields that are not set and do not have default values. If this field is present when invoked with -c, the configuration commands in this field are run on the current server using the scope of the server specified in the serverID field. StreamCommand: type: object description: | The Perforce stream specification defines a single stream. Streams are hierarchical branches with policies that control the structure and the flow of change. Stream hierarchies are based on the stability of the streams, specified by the type you assign to the stream. Development streams are least stable (most subject to change), mainline streams are somewhat stable, and release streams are highly stable. Virtual streams can be used to copy and merge between parent and child streams without storing local data. Task streams are lightweight short-lived branches that are useful for bug fixing or new features that only modify a small subset of the branch data. Stream contents are defined by the paths that you map. By default, a stream has the same structure as its parent (the stream from which it was branched), but you can override the structure, for example to ensure that specified files cannot be submitted or integrated to other streams. properties: stream: type: string description: | Specifies the stream's name (permanent identifier) and its path in the stream depot, in the form `//depotname/streamname`. update: type: string format: date-time description: | The date the stream specification was last modified. access: type: string format: date-time description: | The date and time that the stream specification was last accessed by any Perforce command. owner: type: string description: | The Perforce user or group who owns the stream. The default is the user who created the stream. name: type: string description: | Display name of the stream. Unlike the Stream: field, this field can be modified. Defaults to the streamname portion of the stream path. parent: type: string description: | The parent of this stream. Must be none if the stream's `Type:` is mainline, otherwise must be set to an existing stream identifier of the form `//depotname/streamname`. type: type: string description: | The stream’s type determines the expected flow of change. Valid stream types are `mainline`, `virtual`, `development`, and `release`. - `mainline`: The mainline stream is the parent of all streams in the stream depot. Every stream depot must have at least one mainline stream. - `virtual`: Virtual streams allow merging and copying between parent and child streams without storing local data. Data is passed through to the destination (a non-virtual stream) after applying restrictions on the scope of files defined in the virtual stream’s view. Because virtual streams do not have files in their depot namespace, it is impossible to import a virtual stream. - `release`: More stable than the mainline. Release streams copy from the parent and merge to the parent. - `development`: Less stable than the mainline. Development streams expect to merge from parent streams and copy to the parent. - `task`: Task streams are lightweight short-lived branches that are useful for bug fixing or new features that only modify a small subset of the branch data. Because branched (copied) files are tracked in a set of shadow tables which are later removed, repository metadata is kept to a minimum when using this type of stream. Workspaces associated with task streams see all branched data, but only modified and promoted data is visible to users with access to the stream’s namespace. The default is stream type is development. description: type: string description: | Description of the stream. options: type: string description: | Settings that configure stream behavior as follows: - `[un]locked`: Enable/disable other users' ability to edit or delete the stream. If locked, the stream specification cannot be deleted, and only its owner can modify it. The default is unlocked. - `[all,owner]submit`: Specifies whether all users or only the owner of the stream can submit changes to the stream. The default is allsubmit. If the Owner: of a stream marked ownersubmit is a group, all users who are members of that group can submit changes to the stream. - `[no]toparent`: Specifies whether integrations from the stream to its parent are expected. The default is toparent. - `[no]fromparent`: Specifies whether integrations to the stream from its parent are expected. The default is fromparent for mainline and development streams, and nofromparent for release streams. - `mergeany,mergedown`: Specifies whether the merge flow is restricted or whether merge is permitted from any other stream. For example, the mergeany option would allow a merge from a child to a parent with no warnings. A virtual stream must have its flow options set to notoparent and nofromparent. Flow options are ignored for mainline streams. paths: type: array items: type: string description: | Paths define how files are incorporated into the stream structure. Specify paths using the following format: `path_type view_path [depot_path]` where `path_type` is a single keyword, `view_path` is a file path with no leading slashes, and the optional `depot_path` is a file path beginning with //. The default path is `share ...` Valid path types are: - `share view_path`: Specified files can be synced, submitted, and integrated to and from the parent stream. - `isolate view_path`: Specified files can be synced and submitted, but cannot be integrated to and from the parent stream. - `import view_path [depot_path]`: Specified files can be synced, but cannot be submitted or integrated to and from the parent stream. The `view_path` is mapped as in the parent stream's view, or to an (optional) `depot_path`. The `depot_path` may include a changelist specifier. That stream's client workspaces will be limited to seeing revisions at that change or lower within that depot path. For example, you can specify a depot path like this: `//depot/import/...@1000`. Revisions from changelists greater than 1000 will be automatically hidden from most commands. The changelist limits in effect for a given stream workspace are displayed in a read-only client workspace specification field called ChangeView. - `import+ view_path [depot_path]`: Functions like a standard import path, enabling you to map a path from outside the stream depot to your stream, but unlike a standard import path, you can submit changes to the files in an import+ path. - `exclude view_path`: Specified files cannot be synced, submitted or integrated to and from the parent stream. By default, streams inherit their structure from the parent stream (except mainlines, which have no parent). Paths are inherited by child stream views; a child stream’s path can downgrade the inherited view, but not upgrade it. (For example, a child stream can downgrade a shared path to an isolated path, but if the parent stream defines a path as isolated, its child cannot restore full access by specifying the path as shared.) Note that the `depot_path` is relevant only when the path_type is `import` or `import+`. remapped: type: array items: type: string description: | Reassigns the location of workspace files. To specify the source path and its location in the workspace, use the following syntax: `view_path_1 view_path_2` where `view_path_1` and `view_path_2` are Perforce view paths (omit leading slashes and leading or embedded wildcards; terminal wildcards are fine). For example, to ensure that files are synced to the local ProjectX folder, remap as follows: `... projectX/...` Line ordering in the Remapped: field is significant: if more than one line remaps the same files, the later line takes precedence. Remappings are inherited by child streams and the workspaces associated with them. ignored: type: array items: type: string description: | A list of file or directory names to be ignored in client views. For example: ``` /tmp # ignores files named "tmp" /tmp/... # ignores directories named "tmp" .tmp # ignores file names ending in .tmp ``` Lines in the `Ignored:` field can appear in any order. Ignored files and directories are inherited by child stream client views. StreamsCommand: type: object description: | A summary of a stream in the system, as provided by the `p4 streams` command. properties: stream: type: string description: | Specifies the stream's name (permanent identifier) and its path in the stream depot, in the form `//depotname/streamname`. update: type: string format: date-time description: | The date the stream specification was last modified. access: type: string format: date-time description: | The date and time that the stream specification was last accessed by any Perforce command. owner: type: string description: | The Perforce user or group who owns the stream. The default is the user who created the stream. name: type: string description: | Display name of the stream. Unlike the Stream: field, this field can be modified. Defaults to the streamname portion of the stream path. parent: type: string description: | The parent of this stream. Must be none if the stream's `Type:` is mainline, otherwise must be set to an existing stream identifier of the form `//depotname/streamname`. type: type: string description: | The stream’s type determines the expected flow of change. Valid stream types are `mainline`, `virtual`, `development`, and `release`. - `mainline`: The mainline stream is the parent of all streams in the stream depot. Every stream depot must have at least one mainline stream. - `virtual`: Virtual streams allow merging and copying between parent and child streams without storing local data. Data is passed through to the destination (a non-virtual stream) after applying restrictions on the scope of files defined in the virtual stream’s view. Because virtual streams do not have files in their depot namespace, it is impossible to import a virtual stream. - `release`: More stable than the mainline. Release streams copy from the parent and merge to the parent. - `development`: Less stable than the mainline. Development streams expect to merge from parent streams and copy to the parent. - `task`: Task streams are lightweight short-lived branches that are useful for bug fixing or new features that only modify a small subset of the branch data. Because branched (copied) files are tracked in a set of shadow tables which are later removed, repository metadata is kept to a minimum when using this type of stream. Workspaces associated with task streams see all branched data, but only modified and promoted data is visible to users with access to the stream’s namespace. The default is stream type is development. description: type: string description: | Description of the stream. options: type: string description: | Settings that configure stream behavior as follows: - `[un]locked`: Enable/disable other users' ability to edit or delete the stream. If locked, the stream specification cannot be deleted, and only its owner can modify it. The default is unlocked. - `[all|owner]submit`: Specifies whether all users or only the owner of the stream can submit changes to the stream. The default is allsubmit. If the Owner: of a stream marked ownersubmit is a group, all users who are members of that group can submit changes to the stream. - `[no]toparent`: Specifies whether integrations from the stream to its parent are expected. The default is toparent. - `[no]fromparent`: Specifies whether integrations to the stream from its parent are expected. The default is fromparent for mainline and development streams, and nofromparent for release streams. - `mergeany | mergedown`: Specifies whether the merge flow is restricted or whether merge is permitted from any other stream. For example, the mergeany option would allow a merge from a child to a parent with no warnings. A virtual stream must have its flow options set to notoparent and nofromparent. Flow options are ignored for mainline streams. Triggers: type: object description: | Defines the triggers table, like it would appear in the output to the `p4 triggers` command. properties: triggers: type: array items: type: string description: | A list of trigger definitions. A trigger definition contains four fields that specify the name of the trigger, the type of event that should trigger the execution of the script, the paths that should be affected by the trigger, the location of the script, and other trigger type-dependent information. When the condition specified in a trigger definition is satisfied, the associated script or program is executed. Example: `trig1 change-submit //depot/dir/... "/usr/bin/s1.pl %changelist%"` See the Helix Versioning Engine Administrator Guide for more details on trigger definitions. UserCommand: type: object description: | Create or edit Perforce user specifications and preferences. There are three types of Perforce users: standard users, operator users, and service users. Standard users are the default, and each standard user consumes one Perforce license. The operator user type is intended for system administrators; they are subject to the same restrictions on permissions as any other user, but are further restricted in that they can run only a limited subset of Perforce commands. Service users are intended for inter-server communication in replicated and multi-server environments, and are restricted to an even smaller subset of Perforce commands. Neither operators nor service users consume Perforce licenses. properties: user: type: string description: The Perforce username. type: type: string enum: ["standard", "operator", "service"] description: | Type of user: standard, operator, or service. Once you set the type, you cannot change it. authMethod: type: string enum: ["perforce", "ldap"] description: | One of the following: perforce or ldap. Specifying perforce enables authentication using Perforce’s internal db.user table or by way of an authentication trigger. This is the default unless it is overridden with the auth.default.method configurable. Specifying ldap enables authentication against AD/LDAP servers specified by the currently active LDAP configurations. email: type: string description: | The user’s email address. By default, this is user@client. update: type: string format: date-time description: | The date and time this specification was last updated. access: type: string format: date-time description: | The date and time this user last ran a Perforce command. fullName: type: string description: The user's full name. jobView: type: string description: | Jobs matching this jobview appear on any changelists created by this user. Jobs that are fixed by the changelist should be left in the changelist when it's submitted with p4 submit; other jobs should be deleted from the form before submission. password: type: string format: password description: The user's password. passwordChange: type: string format: date-time description: | The date and time of the user’s last password change. If the user has no password, this field is blank. reviews: type: array items: type: string description: | A list of files the user would like to review. This field can include exclusionary mappings. UsersCommand: type: object properties: user: type: string description: The Perforce username. type: type: string enum: ["standard", "operator", "service"] description: | Type of user: standard, operator, or service. Once you set the type, you cannot change it. email: type: string description: | The user’s email address. By default, this is user@client. update: type: string format: date-time description: | The date and time this specification was last updated. access: type: string format: date-time description: | The date and time this user last ran a Perforce command. fullName: type: string description: The user's full name. hasPassword: type: string description: If 'enabled', the password has been set on the user.