/* 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. */ function ServerCommand(data) { Object.defineProperties(this, { /* 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. */ "serverID": { value: data ? data.serverID : undefined, enumerable: true, writable: true }, /* 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. */ "type": { value: data ? data.type : undefined, enumerable: true, writable: true }, /* 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 */ "services": { value: data ? data.services : undefined, enumerable: true, writable: true }, /* The P4NAME associated with this server. You can leave this blank or you can set it to the same value as the serverid. */ "name": { value: data ? data.name : undefined, enumerable: true, writable: true }, /* The P4PORT used by this server. */ "address": { value: data ? data.address : undefined, enumerable: true, writable: true }, /* 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. */ "externalAddress": { value: data ? data.externalAddress : undefined, enumerable: true, writable: true }, /* An optional description for this server. */ "description": { value: data ? data.description : undefined, enumerable: true, writable: true }, /* The service user name used by the server. */ "user": { value: data ? data.user : undefined, enumerable: true, writable: true }, /* 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. */ "clientDataFilter": { value: data ? data.clientDataFilter : undefined, enumerable: true, writable: true }, /* 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. */ "revisionDataFilter": { value: data ? data.revisionDataFilter : undefined, enumerable: true, writable: true }, /* 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. */ "archiveDataFilter": { value: data ? data.archiveDataFilter : undefined, enumerable: true, writable: true }, /* 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. */ "distributedConfig": { value: data ? data.distributedConfig : undefined, enumerable: true, writable: true } }); } module.exports = ServerCommand;
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 19553 | swellard | Move and rename clients | ||
//guest/perforce_software/helix-web-services/main/source/clients/2016.1.0/javascript/lib/models/server_command.js | |||||
#2 | 19169 | tjuricek | JavaScript Client SDK jobs CRUD test, with supprt for "additionalProperties" in the swagger definition. | ||
#1 | 19053 | tjuricek |
Rebuild JavaScript Client SDK. The JavaScript client now is a "typed" approach that tends to be similar in approach to the other clients, based on the swagger definition for the platform version. Importantly, client SDK tests are individual scripts (that run under node) that are actually controlled via TestNG. This approach now lets us use a consistent test reporting format so we can at least collect reports from each of the jobs. The documentation is still in progress, that I want to validate as the tests are generated. |