Page History

...

Usage: deploy-git.sh [Command] [Options] [Switches]

  Commands:
    get-item            --folder [--recursive] [--local]
    store-item         [--path]  [--type] [--folder] [--recursive] [--local] [--controller-id] 
                                 [-no-draft] [--no-deployed] [--no-released]
    update-item        [--path]  [--type] [--folder] [--recursive] [--local]
    delete-item        [--path]  [--type] [--folder] [--local]
    checkoutclone               --folder [--local] [--branch | --tag]remote-url
    clone      checkout            --folder [--local] [--branch | -remote-urltag]
    add                 --folder [--local]
    commit              --folder [--local] --message
    push                --folder [--local]
    pull                --folder [--local]
    get-credentials
    store-credentials   --server --user-account --user-name --user-mail 
                                [--user-password | --user-access-token | --user-private-key]
    delete-credentials  --server

  Options:
    --url=<url>                        | required: JOC Cockpit URL
    --controller-id=<id[,id]>          | required: Controller ID
    --user=<account>                   | required: JOC Cockpit user account
    --password=<password>              | optional: JOC Cockpit password
    --ca-cert=<path>                   | optional: path to CA Certificate used for JOC Cockpit login
    --client-cert=<path>               | optional: path to Client Certificate used for login
    --client-key=<path>                | optional: path to Client Key used for login
    --timeout=<seconds>                | optional: timeout for request, default: 60
    --folder=<folder[,folder]>         | optional: list of inventory folders holding objects
    --path=<path[,path]>               | optional: list of inventory paths to objects
    --type=<type[,type]>               | optional: list of object types such as WORKFLOW,SCHEDULE
    --branch=<identifier>              | optional: Git branch identified by name, default: master
    --tag=<tag[,tag]>                  | optional: Git branch identified by tags
    --message=<text>                   | optional: Git commit message
    --server=<host>                    | optional: Git server
    --user-account=<account>           | optional: Git authentication user account
    --user-name=<text>                 | optional: Git authentication user name
    --user-mail=<e-mail>               | optional: Git authentication user e-mail address
    --user-password=<password>         | optional: Git authentication user password
    --user-access-token=<identifier>   | optional: Git authentication user access token
    --user-private-key=<path>          | optional: Git authentication user private key file
    --remote-url=<url>                 | optional: Git remote repository URL
    --audit-message=<string>           | optional: audit log message
    --audit-time-spent=<number>        | optional: audit log time spent in minutes
    --audit-link=<url>                 | optional: audit log link
    --log-dir=<directory>              | optional: path to directory holding the script's log files

  Switches:
    -h | --help                        | displays usage
    -v | --verbose                     | displays verbose output, repeat to increase verbosity
    -p | --password                    | asks for password
    -l | --local                       | uses repository for local objects
    -r | --recursive                   | specifies folders to be looked up recursively
    -u | --user-password               | asks for Git account password
    --no-draft                         | excludes draft objects
    --no-deployed                      | excludes deployed objects
    --no-released                      | excludes released objects
    --show-logs                        | shows log output if --log-dir is used
    --make-dirs                        | creates directories if they do not exist

Anchor
commands commands

Commands

• get-item
  • Reads scheduling objects from JOC Cockpit's Git repository. Objects will be returned in JSON format.
  • The command is used alternatively
    • with the --path and --type options to specify an individual object. One of the following object types has to be specified:
      • Deployable object types: WORKFLOW, FILEORDERSOURCE, JOBRESOURCE, NOTICEBOARD, LOCK
      • Releasable object types: INCLUDESCRIPT, SCHEDULE, WORKINGDAYSCALENDAR, NONWORKINGDAYSCALENDAR, JOBTEMPLATE, REPORT
    • with the --folder option to specify all objects in the related inventory folder to be deployed. The --recurse switch can be used to process sub-folders recursively.
• store-item
  • Stores scheduling objects of JOC Cockpit's inventory to JOC Cockpit's Git repository.
  • The following switches are available to limit objects that should be stored:
    • The --no-draft switch excludes draft objects from being stored to JOC Cockpit's Git repository.
    • The --no-deployed switch excludes deployed objects from being stored to JOC Cockpit's Git repository.
    • The --no-released switch excluses released objects from being stored to JOC Cockpit's Git repository.
• update-item
  
  • Updates JOC Cockpit's inventory from scheduling objects available in JOC Cockpit's Git repository.
• delete-item

  • Deletes scheduling objects from JOC Cockpit's Git repository.

  • Later commit and push commands will apply changes.
• clone
  • Clones a remote Git repository to a JOC Cockpit Git repository.
  • The command is used with the --remote-url option to identify the remote Git repository. Frequently the syntax git@<git-server>:<owner>/<repository> is used, for example git@github.com:sos-berlin/js7-demo-inventory-rollout-test.
• checkout
  • A specific branch from the remote Git repository can be checked out using the --branch or --tag options that identify the branch.
• add
  • Adds changes to JOC Cockpit's Git repository.
• commit
  • Commits changes to JOC Cockpit's Git repository.
  • The command is used with the --folder option to specify the inventory folder that is mapped to the Git repository. The --message option is used to specify a message that  typically becomes visible when displaying commits to a repository.
• push
  • Pushes objects to the remote Git repository.
  • The command is used with the --folder option to specify the inventory folder that is mapped to the Git repository.
• pull
  • Pulls objects from the remote Git repository to JOC Cockpit's Git repository. Objects in JOC Cockpit's Git repository will be removed, addedd or updated.
  • The command is used with the --folder option to specify the inventory folder that is mapped to the Git repository.
• get-credentials
  • Reads Git credentials from the user's profile in JOC Cockpit. If credentials for more than one Git Server are available then they will be returned.
  • Stores Git credentials to the user's profile in JOC Cockpit. If credentials for the same Git Server exist, then they will be overwritten.
• store-credentials
  • Stores Git credentials to the user's profile in JOC Cockpit.
  • The command is used with the --server option to specify the Git Server for which credentials will be stored.
  • For authentication with Git one of the --user-password, --user-access-token or --user-private-key options can be used.
    • The location of a private key file should be specified from an absolute path that is readable for the JOC Cockpit service.
    • Users have to store the private key file to the related location.
• delete-credentials
  • Removes Git credentials from the user's profile in JOC Cockpit.
  • The command is used with the --server option to specify the Git Server for which credentials will be deleted
• register
  • Allows registering a Controller. The command comes in two flavors:
    • register a Standalone Controller using the --primary-url option.
    • register a Controller Cluster using the --primary-url and --secondary-url options.
  • The URLs specify the protocol, host and optionally port by which the Controller instance can be accessed from JOC Cockpit, for example http://localhost:4444.
  • Controller instances are assigned a Controller ID on installation. When registering the Controller it will automatically use the given Controller ID.
• unregister
  • Allows unregistering a Controller specifying the --controller-id option. Unregistering a Controller deletes the Controller and related Agents from the inventory
• check
  
  • Tests the connection between JOC Cockpit and a Controller instance. The operation is available before a Controller is registered.
  • The --controller-url must be specified that is used from JOC Cockpit to connect to the Controller. 
• store-agent

  • When Agents are stored, then they are added or updated in the inventory and are set to the not deployed status. The command comes in two flavors:

    • store Standalone Agent: requires to specify the --controller-id and --agent-id options that specify the unique identifier of an Agent. The Agent ID cannot be changed later on. The --agent-name option specifies the unique name of an Agent that can be changed later on. The --agent-url option specifies the protocol, host and optionally port by which the Agent can be accessed from the Controller..
    • store Agent Cluster: requires to specify the --controller-id, --agent-id and --agent-name options. An Agent Cluster includes a Primary and Secondary Director Agent. 
      • The Primary Director Agent is specified from the --primary-subagent-id and --primary-url options that are used similarly to above --agent-id and --agent-url options.
      • The Secondary Director Agent is specified from the --secondary-subagent-id and --secondary-url options that are used similarly to above --agent-id and --agent-url options.
  • The deploy-agent command can be used to deploy the Agent configuration.
• delete-agent
  • When Agents are deleted, then they will be deleted from the Controller and from the inventory.
  • Deletion of Agents will be denied by the Controller if we find deployed workflows that hold jobs assigned the Standalone Agent or related Subagent Cluster of an Agent Cluster. The JS7 - Unix Shell CLI for Workflow Deployment offers commands to revoke related workflows.
  • The command is used with the --controller-id and --agent-id options to identify the related Agent.
• deploy-agent
  • When Agents are deployed, then the Agent configuration will be made available to the Controller which connects to the related Agent. As a prerequisite for deployment the Agent must be up & running and must be reachable for the Controller to establish a connection. The same applies to Subagents that have been added to an Agent Cluster using the store-subagent command.
  • The command is used with the --controller-id and --agent-id options to identify the related Agent. For deployment of an Agent Cluster the --cluster switch must be used.
• revoke-agent
  • When Agents are revoked then the Agent configuration is deleted from the Controller, but remains in place with the inventory and will be set to the not deployed status.
  • Revocation of Agents will be denied by the Controller if we find deployed workflows that hold jobs assigned the Standalone Agent or related Subagent Cluster of an Agent Cluster. The JS7 - Unix Shell CLI for Workflow Deployment offers commands to revoke related workflows.
  • The command is used with the --controller-id and --agent-id options to identify the related Agent. For revocation of an Agent Cluster the --cluster switch must be used.
• store-subagent
  • Subagents are used in an Agent Cluster acting as worker nodes to execute jobs. When Subagents are stored, then they are added or updated in the inventory and will be set to the not deployed status. Subagents are not deployed individually. Instead, they are deployed with the Agent Cluster using the deploy-agent command.
  • The command is used with the --controller-id and --agent-id options which identify the Agent Cluster. The --subagent-id and --subagent-url options specify the unique identifier of a Subagent and its URL.
• delete-subagent
  • Subagents are deleted from the Agent Cluster and related Subagent Clusters. The operation deletes Subagents from the Agent Cluster and from the inventory.
  • The command is used with the --controller-id and --subagent-id options to identify the related Subagent.
• store-cluster
  • Subagent Clusters implement clustering from the selection of the Subagents involved and from the scheduling mode being active-passive (fixed-priority) or active-active (round-robin).
  • To store a Subagent Cluster users specify the --controller-id and --agent-id options that identify the Agent Cluster. The --cluster-id option specifies the unique identifier of the cluster to be created. The --subagent-id option specifies one or more Subagents spearated by comma that are used in the cluster. For an active-passive cluster the first Subagent specified will execute the jobs and if it becomes unavailable then the next Subagent will be used.
  • The --priority option specifies an active-passive or active-active cluster. The option accepts one fo the values first (active-passive) or next (active-active). Default: first.
• delete-cluster
  • The Subagent Cluster is deleted from the Agent Cluster and from the inventory. Subagents used in the Subagent Cluster are not deleted.
  • Deletion of a Subagent Cluster will be denied by the Controller if we find deployed workflows that hold jobs assigned the Subagent Cluster. The JS7 - Unix Shell CLI for Workflow Deployment offers commands to revoke related workflows.
  • The command is used with the --controller-id and --cluster-id options to identify the Subagent Cluster.
• deploy-cluster
  • The Subagent Cluster is made available to the Agent Cluster. A deployed Subagent Cluster can be used for assignment to jobs.
  • The command is used with the --controller-id and --cluster-id options to identify the Subagent Cluster.
• revoke-cluster
  • The Subagent Cluster is deleted from the Agent Cluster but remains in place with the inventory and is set to the not deployed status.
  • Revocation of a Subagent Cluster will be denied by the Controller if we find deployed workflows that hold jobs assigned the Subagent Cluster. The JS7 - Unix Shell CLI for Workflow Deployment offers commands to revoke related workflows.
  • The command is used with the --controller-id and --cluster-id options to identify the Subagent Cluster.
• export-agent

  • Agent configurations can be exported to an archive file using the --file option. The archive file will be created in .zip or .tar.gz format using the --format option.

• import-agent
  • For import of Agent configurations users can specify that existing Agent configurations with the same Agent IDs should be overwritten using the --overwrite switch.
• encrypt
  • Allows to encrypt a value using the --in option. If used to encrypt a file then --infile and --outfile options must be specified.
  • The --cert option specifies the path to a file holding the Certificate used for encryption.
  • Encryption is performed by Java libraries that are looked up in the ./lib sub-directory of the  JS7 Unix Shell CLI. For details see JS7 - Encryption and Decryption.
• decrypt
  • Allows to decrypt a value using the --in option. If used to decrypt a file then --infile and --outfile options must be specified.
  • The --key option specifies the path to the Private Key used for decryption. If the Private Key is protected by a password, then the --key-password option or switch must be specified.
  • Decryption is performed by Java libraries that are looked up in the ./lib sub-directory of the JS7 Unix Shell CLI.

Anchor
options options

Options

...