...

...

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

  Commands:
    getlist-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]
    clone   checkout            --folder [--local] [--branch | --tag]remote-url
    checkout  clone               --folder [--local] [--remote-urlbranch | --tag]
    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]><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]><type>                      | optional: list of object typestype 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><token>        | 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

• list-item
  • Returns the list of scheduling objects from JOC Cockpit's Git repository. The list 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 include all objects in the related folder to be returned. The --recursive 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 can be used 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 excludes released objects from being stored to JOC Cockpit's Git repository.
  • Later commit and push commands will apply changes.
• update-item
  
  • Updates the JOC Cockpit inventory from scheduling objects available in JOC Cockpit's Git repository.
• delete-item

  • Deletes scheduling objects from JOC Cockpit's Git repository. The operation does not affect existence of objects in JOC Cockpit's inventory.

  • 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 is checked out using the --branch or --tag options to 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 in a Git Server.
  • The command returns the commit hash created by Git when committing changes.
• push
  • Pushes objects from JOC Cockpit's Git repository 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, added 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.
• 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 must be used.
    • The location of a private key file must 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
  • Deletes Git credentials from the user's profile in JOC Cockpit
• 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.

...

• --url
  • Specifies the URL by which JOC Cockpit is accessible using <http|https>://<host>:<port>.
  • Example: http://centostest-primary.sos:4446
  • Example: https://centostest-primary.sos:4443
• --user
  • Specifies the user account for login to JOC Cockpit. If JS7 - Identity Services are available for Client authentication certificates that are specified with the --client-cert and --client-key options then their common name (CN) attribute has to match the user account.
  • If a user account is specified then a password can be specified using the --password option or interactive keyboard input can be prompted using the -p switch.
• --password
  • Specifies the password used for the account specified with the --user option for login to JOC Cockpit.
  • Password input from the command line is considered insecure.
    • Consider use of the -p switch offering a secure option for interactive keyboard input.
    • Consider use of the encrypt command to encrypt a password: ./deploy-controller.sh encrypt --in=root --cert=encrypt.crt.
      • The encryption result will include the prefix enc: followed by the encrypted symmetric key, initialization vector and encrypted secret separated by space.
      • If an encrypted password is specified, then it will be decrypted using the Private Key file: ./deploy-controller.sh <command> --password="enc:BF8J8KP7TPlxy..." --key=encrypt.key.
• --ca-cert
  • Specifies the path to a file in PEM format that holds the Root CA Certificate and optionally Intermediate CA Certificates to verify HTTPS connections to JOC Cockpit.
• --client-cert
  • Specifies the path to a file in PEM format that holds the Client Certificate if HTTPS mutual authentication is used..
• --client-key
  • Specifies the path to a file in PEM format that holds the Client Private Key if HTTPS mutual authentication is used..
• --timeout
  • Specifies the maximum duration for requests to the JS7 REST Web Service. Default: 60 seconds.
• --controller-id
  • Specifies the identification of the Controller.
• --controller-url
  • When used with the check command, specifies the protocol, host and optionally port of the Controller instance to which the connection is tested.
• --primary-url
  • When used with the register command, specifies the protocol, host and optionally port of a Standalone Controller or Primary Controller instance in a cluster. The JOC Cockpit will connect to the Controller instance using the URL specified.
  • When used with the store-agent command for an Agent Cluster, specifies the protocol, host and optionally port of the Primary Director Agent. The Controller will connect to the Director Agent instance using the URL specified.
• --primary-cluster-url
  • Specifies the URL used by the Pirmary Controller instance to connect to the Secondary Controller instance in a cluster. The URL can be specified if it is different from the value specified with the --primary-url option used for access from JOC Cockpit to the Primary Controller instance.
  • .The option can be used for example if a proxy service is active between Controller instances.
• --primary-title
  • When used with the register command specifies the title of a Standalone Controller or Primary Controller instance.
  • When used with the store-agent command specifies the title of the Primary Director Agent in an Agent Cluster.
• --primary-subagent-id
  • When used with the store-agent command specifies the identifier of the Primary Director Agent in an Agent Cluster.
• --secondary-url
  • When used with the register command, specifies the protocol, host and optionally port of a Secondary Controller instance in a cluster. The JOC Cockpit will connect to the Controller instance using the URL specified.
  • When used with the store-agent command for an Agent Cluster specifies the protocol, host and optionally port of the Secondary Director Agent. The Controller will connect to the Director Agent instance using the URL specified.
• --secondary-cluster-url
  • Specifies the URL used by the Secondary Controller instance to connect to the Primary Controller instance in a cluster. The URL can be specified if it is different from the value specified with the --secondary-url option used for access from JOC Cockpit to the Secondary Controller instance.
  • .The option can be used for example if a proxy service is active between Controller instances.
• --secondary-title
  • When used with the register command, specifies the title of the Secondary Controller instance.
  • When used with the store-agent command, specifies the title of the Secondary Director Agent in an Agent Cluster.
• --secondary-subagent-id
  • When used with the store-agent command, specifies the identifier of the Secondary Director Agent in an Agent Cluster.
• --file
  • Specifies the location of an archive file that is used with export-agent and import-agent commands.
  • On export an existing archive file will be overwritten.
• --format
  • Specifies the format of the archive file indicated with the --file option.
  • The format can be one of ZIP or TAR_GZ. Default: ZIP. The JS7 can process archive files in .zip format on Unix.
• --agent-id
  • The Agent ID specifies a unique identifier for a Standalone Agent or Agent Cluster that cannot be changed later on.
  • Agents are identified from their Agent ID.
• --agent-name
  • The Agent name specifies a unique identifier for a Standalone Agent or Agent Cluster that can be changed later on..
• --agent-url
  • When used with the store-agent command, the option specifies the protocol, host and optionally port of a Standalone Agent.
• --title
  • Specifies the title of a Controller, Agent or Subagent Cluster with related register, store-agent and store-cluster commands.
• --alias
  • When used with the store-agent command, the option specifies alternative names for a Standalone Agent or Agent Cluster. Any number of alias names can be specified separated by comma.
  • Alias names can be used for assignment of Agents to jobs.
• --process-limit
  • Specifies the maximum number of processes running in parallel in a Standalone Agent or Agent Cluster.
  • In an Agent Cluster the maximum number of processes is counted for all Subagents.
• --subagent-id
  • When used with the store-subagent and delete-subagent commands, the option specifies the related Subagent.
  • When used with the store-cluster command, any number of Subagent IDs can be specified separated by comma. This allows to specify Subagents that are members of a Subagent Cluster.
• --subagent-url
  • The option is used with the store-subagent command to specify the proocol, host and port by which the Subagent can be reached.
• --role
  • When used with the store-subagent command, the option specifies the Subagent's role. In an Agent Cluster we find the following roles:
    • Primary Director Agent
    • Secondary Director Agent
    • No Director Agent
  • The option accepts the values primary, secondary, no. Default: no.
• --cluster-id
  • Specifies the unique identifier of a Subagent Cluster. The Subagent Cluster ID cannot be changed after the Subagent Cluster is created.
  • The option is used with the store-cluster , delete-cluster, deploy-cluster and revoke-cluster commands.
• --priority
  • Specifies an active-passive, active-active or metrics Subagent Cluster. The option accepts one of the values first (active-passive), next (active-active) or a metrics expression. Default: first.
  • The option is used with the store-cluster command.
• --key
  • When used with the decrypt command, specifies the path to a file that holds the Private Key in PEM format used for decryption.
• --cert
  
  • When used with the encrypt command, specifies the path to a file that holds the CA-signed or self-signed X.509 Certificate. Alternatively, the path to a file holding the Public Key can be specified. The Certificate or Public Key is expected in PEM format.
  • For encryption the Certificate or Public Key must match the Private Key used for later decryption specified with the --key option.
• --key-password
  • When used with the decrypt command, specifies the password for access to the Private Key file using the --key option.
  • Password input from the command line is considered insecure.
    • Consider use of the -k switch or more elaborate mechanisms, for example by temporarily populating the system keystore form a security key such as a YubiKey® or similar.
    • Consider use of encrypted passwords as explained with the --password option.
• --in
  • When used with the encrypt and decrypt commands, specifies the input value that should be encrypted or decrypted.,
  • One of the options --in or --infile can be specified.
• --infile
  • When used with the encrypt and decrypt commands, specifies the path to the input file that should be encrypted/decrypted.
  • One of the options --in or --infile can be specified. This option requires use of the --outfile option.
• --outfile
  • When used with the encrypt command, specifies the path to the output file that will be created holding the encrypted content of the input file.
  • When used with the decrypt command, specifies the path to the output file that will be created holding the decrypted content of the input file.
  • The option is required if the --infile option is specified
• --java-home
  • When used with the encrypt and decrypt commands or with encrypted passwords, specifies the Java home directory. By default the JAVA_HOME environment variable is used to determine the location of Java.
  • The Java home directory is the top-level directory of a Java installation. The directory includes the bin sub-directory and java executable.
• --java-lib
  • When used with the encrypt and decrypt commands or with encrypted passwords, a number of Java libraries are required to perform encryption/decryption.
  • The Java libraries are expected in the lib sub-directory of the JS7 Unix Shell CLI. Default: ./lib.
• --audit-message
  • Specifies a message that is made available to the Audit Log.
  • Specification of Audit Log messages can be enforced on a per user basis and for a JS7 environment.
• --audit-time-spent
  • Specifies the time spent to perform an operation which is added to the Audit Log.
  • The option can be specified if the --audit-message option is used.
• --audit-link
  • Specifies a link (URL) which is added to the Audit Log.
  • The option can be specified if the --audit-message option is used.
• --log-dir
  • If a log directory is specified then the script will log information about processing steps to a log file in this directory.
  • File names are created according to the pattern: deploy-controller.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.log
  • For example: deploy-controller.2022-03-19T20-50-45.log

...

• -h | --help
  • Displays usage.
• -v | --verbose
  • Displays verbose log output that includes requests and responses with the JS7 REST Web Service.
  • When used twice as with -v -v then curl verbose output will be displayed.
• -p | --password
  • Asks the user for interactive keyboard input of the password used for the account specified with the --user option..
  • The switch is used for secure interactive input as an alternative to use of the option --password=<password>.
• -k | --key-password
  • Asks the user for interactive keyboard input of the password used for access to a keystore or key file specified with the --keystore or --key options.
  • The switch is used for secure interactive input as an alternative to use of the --key-password=<password> option.
• -o | --overwrite
  • Specifies that Agent configurations holding the same Agent ID will be overwritten on import when used with the import-agent command.
• -i | --hide
  • If a Standalone Agent is added or is updated using the store-agent command, then the switch specifies that the Agent will not be visible in the JOC Cockpit Dashboard view and Resources->Agents view..
• -c | --cluster
  • Specifies that the operation is applied to an Agent Cluster if the deploy-agent or revoke-agent commands are used.
• --show-logs
  • Displays the log output created by the script if the --log-dir option is used.
• --make-dirs
  • If directories are missing that are indicated with the --log-dir option then they will be created.

...

• • server option to specify the Git Server for which credentials will be deleted.

Anchor
options options

Options

• --url
  • Specifies the URL by which JOC Cockpit is accessible using <http|https>://<host>:<port>.
  • Example: http://centostest-primary.sos:4446
  • Example: https://centostest-primary.sos:4443
• --user
  • Specifies the user account for login to JOC Cockpit. If JS7 - Identity Services are available for Client authentication certificates that are specified with the --client-cert and --client-key options then their common name (CN) attribute has to match the user account.
  • If a user account is specified then a password can be specified using the --password option or interactive keyboard input can be prompted using the -p switch.
• --password
  • Specifies the password used for the account specified with the --user option for login to JOC Cockpit.
  • Password input from the command line is considered insecure.
    • Consider use of the -p switch offering a secure option for interactive keyboard input.
    • Consider use of the encrypt command to encrypt a password: ./deploy-controller.sh encrypt --in=root --cert=encrypt.crt.
      • The encryption result will include the prefix enc: followed by the encrypted symmetric key, initialization vector and encrypted secret separated by space.
      • If an encrypted password is specified, then it will be decrypted using the Private Key file: ./deploy-controller.sh <command> --password="enc:BF8J8KP7TPlxy..." --key=encrypt.key.
• --ca-cert
  • Specifies the path to a file in PEM format that holds the Root CA Certificate and optionally Intermediate CA Certificates to verify HTTPS connections to JOC Cockpit.
• --client-cert
  • Specifies the path to a file in PEM format that holds the Client Certificate if HTTPS mutual authentication is used..
• --client-key
  • Specifies the path to a file in PEM format that holds the Client Private Key if HTTPS mutual authentication is used..
• --timeout
  • Specifies the maximum duration for requests to the JS7 REST Web Service. Default: 60 seconds.
• --controller-id
  • Specifies the identification of the Controller.
• --folder
  • When used with commands, specifies the JOC Cockpit's inventory folder to which the command is applied.
    • For use with the update-item, store-item and delete-item commands more than one folder can be specified separated by comma, for example: --folder=/TestRepo/Accounting,/TestRepo/Reporting
  • The --recursive switch is used If sub-folders should be processed recursively.
• --path
  • When used with the store-item , update-item and delete-item commands, specifies the path of an object including folder, sub-folders and object name.
  • Use of the --path option requires specification of the --type option to determine the object type.
  • The option is used alternatively to specification of a folder using the --folder option.
• --type
  • When used with the store-item , update-item and delete-item commands and the --path option, specifies the type of object that should be processed:
    • Deployable object types: WORKFLOW, FILEORDERSOURCE, JOBRESOURCE, NOTICEBOARD, LOCK
    • Releasable object types: INCLUDESCRIPT, SCHEDULE, WORKINGDAYSCALENDAR, NONWORKINGDAYSCALENDAR, JOBTEMPLATE, REPORT
  • Use of the option is required if the --path option is used.
• --branch
  • When used with the checkout command specifies the name of the Git repository branch to be checked out.
• --tag
  • When used with the checkout command specifies the tag that identifies the Git repository branch to be checked out. If more than one tag is used, they are separted by comma, for example: --tag=prod,v1.12
• --message
  • When used with the commit command, specifies the message that explains the purpose of the commit operation.
• --server
  • When used with the store-credentials and delete-credentials commands, specifies the hostname of the Git Server.
  • Git credentials are stored on a per Git Server basis.
• --user-account
  • When used with the store-credentials command, specifies the account used for authentication with the Git Server.
• --user-name
  • When used with the store-credentials command, specifies the user name used for authentication with the Git Server.
• --user-mail
  • When used with the store-credentials command, specifies the e-mail address used for authentication with the Git Server.
• --user-password
  • When used with the store-credentials command, specifies the password used for authentication with the Git Server.
  • Password input from the command line is considered insecure.
    • Consider use of the -u switch that asks for interactive keyboard input of the password.
    • The switch is used for secure interactive input as an alternative to use of the --user-password=<password> option.
  • Only one of --user-password, --user-access-token or --user-private-key options can be used.
• --user-access-token
  • When used with the store-credentials command, specifies the access token used for authentication with the Git Server.
  • Only one of --user-password, --user-access-token or --user-private-key options can be used.
• --user-private-key
  • When used with the store-credentials command, specifies the path to a private key file used for authentication with the Git Server.
    • The location of a private key file must 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.
  • Only one of --user-password, --user-access-token or --user-private-key options can be used.
• --remote-url
  • When used with the clone command, specifies the URL of the repository to be cloned.
  • Frequently the syntax git@<git-server>:<owner>/<repository> is used, for example: git@github.com:sos-berlin/js7-demo-inventory-rollout-test
• --audit-message
  • Specifies a message that is made available to the Audit Log.
  • Specification of Audit Log messages can be enforced on a per user basis and for a JS7 environment.
• --audit-time-spent
  • Specifies the time spent to perform an operation which is added to the Audit Log.
  • The option can be specified if the --audit-message option is used.
• --audit-link
  • Specifies a link (URL) which is added to the Audit Log.
  • The option can be specified if the --audit-message option is used.
• --log-dir
  • If a log directory is specified then the script will log information about processing steps to a log file in this directory.
  • File names are created according to the pattern: deploy-controller.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.log
  • For example: deploy-controller.2022-03-19T20-50-45.log

Anchor
switches switches

Switches

• -h | --help
  • Displays usage.
• -v | --verbose
  • Displays verbose log output that includes requests and responses with the JS7 REST Web Service.
  • When used twice as with -v -v then curl verbose output will be displayed.
• -p | --password
  • Asks the user for interactive keyboard input of the password used for the account specified with the --user option..
  • The switch is used for secure interactive input as an alternative to use of the option --password=<password>.
• -l | --local
  • Specifies a JOC Cockpit Git repository of type "local" to be used:
    • Repositories of type "local" hold object types that are specific for a scheduling environment and should not be deployed using Git and are stored to a separate repository.
      • Location: <jetty-base>/resources/joc/repositories/local
    • Repositories of type "rollout" hold object types that should be deployed using Git.
      • Location: <jetty-base>/resources/joc/repositories/rollout
    • Which object types make it for which repository type can be specified from settings, see JS7 - Inventory Git Integration.
  • If the switch is not specified, then the repository type "rollout" is assumed.
• -r | --recursive
  • When used with the --folder option, specifies that sub-folders should be processed recursively.
• -u | --user-password
  • Asks the user for interactive keyboard input of the password used for authentication with a Git Server when using the store-credentials command.
  • The switch is used for secure interactive input as an alternative to use of the --user-password=<password> option.
• --no-draft
  • Specifies that draft objects will be excluded from Git operations.
• --no-deployed
  • Specifies that deployed objects will be excluded from Git operations.
  • This applies to deployable object types such as WORKFLOW, FILEORDERSOURCE, JOBRESOURCE, NOTICEBOARD, LOCK.
• --no-released
  • Specifies that released objects will be excluded from Git operations.
  • This applies to releasable object types such as INCLUDESCRIPT, SCHEDULE, WORKINGDAYSCALENDAR, NONWORKINGDAYSCALENDAR, JOBTEMPLATE, REPORT.
• --show-logs
  • Displays the log output created by the script if the --log-dir option is used.
• --make-dirs
  • If directories are missing that are indicated with the --log-dir option then they will be created.

Anchor
exit_codes exit_codes

Exit Codes

• 0: operation successful
• 1: argument errors
• 3: no objects found
• 4: JS7 REST Web Service is not reachable or reports errors

Examples

The following examples illustrate use cases for automated deployment to Git repositories.

Managing Git Credentials

Credentials for a Git Server can be managed from the JOC Cockpit GUI using JS7 - Profiles - Git Management.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# get credentials
./deploy-git.sh get-credentials    "${request_options[@]}"

# store credentials
./deploy-git.sh store-credentials  "${request_options[@]}" --server=github.com --user-account=community \
                                   --user-name="Community" --user-mail="community@sos-berlin.com" \
                                   --user-private-key=/var/sos-berlin.com/js7/joc/resources/joc/repositories/private/sos-community.rsa

# delete credentials
./deploy-git.sh delete-credentials "${request_options[@]}" --server=github.com

Cloning a Git Repository

A remote Git repository is cloned to a JOC Cockpit Git repository and is mapped to a JOC Cockpit inventory folder

• 0: operation successful
• 1: argument errors
• 3: no objects found
• 4: JS7 REST Web Service is not reachable or reports errors

Examples

The following examples illustrate use cases for automated deployment to Git repositories.

Managing Git Credentials

Credentials for a Git Server can be managed from the JOC Cockpit GUI using JS7 - Profiles - Git Management.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# getclone credentialsrepository
./deploy-git.sh get-credentials     clone    "${request_options[@]}" --folder=/TestRepo --remote-url="git@github.com:sos-berlin/js7-demo-inventory-rollout-test"

# optionally checkout repository if a specific branch should be used
./deploy-git.sh checkout "${request_options[@]}"

#  --folder=/TestRepo --branch=main

Managing Scheduling Objects in a Git Repository

Listing Scheduling Objects from a Git Repository

The operation will return the list of scheduling objects available in JOC Cockpit's Git repository.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# list items from JOC Cockpit rollout repository
./deploy-git.sh list-item    "${request_options[@]}" --folder=/TestRepo --recursive

# list items from JOC Cockpit local repositorystore credentials
./deploy-git.sh store-credentials  "${request_options[@]}" --server=github.com --user-account=community \
                                                           --user-name="Community" --user-mail="community@sos-berlin.com" \
                                                           --user-private-key=/var/sos-berlin.com/js7/joc/resources/joc/repositories/private/sos-community.rsa

# delete credentials
./deploy-git.sh delete-credentialslist-item    "${request_options[@]}" --server=github.com

Cloning a Git Repository

folder=/TestRepo --recursive --local

Storing Scheduling Objects to a Git Repository

The operation will store scheduling objects from JOC Cockpit's inventory to JOC Cockpit's Git repositoryA Git repository can be cloned and mapped to a JOC Cockpit inventory folder.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# store items to JOC Cockpit rollout repository: folder
./deploy-git.sh store-item  "${request_options[@]}" --folder=/TestRepo --recursive

# clone repository store items to JOC Cockpit rollout repository: object path and type of deployed object
./deploy-git.sh clone  store-item  "${request_options[@]}" --folderpath=/TestRepo/03_VariablesPassing/jdwVariablesAdHoc --remote-url="git@github.com:sos-berlin/js7-demo-inventory-rollout-test"type=WORKFLOW --no-draft

# optionally checkoutstore items to JOC Cockpit local repository: ifobject apath specificand branchtype shouldof bedraft usedobject
./deploy-git.sh store-item checkout "${request_options[@]}" --folderpath=/TestRepo/03_VariablesPassing/jdjVariablesJobResource --branch=main

Managing Scheduling Objects in a Git Repository

Getting Scheduling Objects from a Git Repository

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# get items from local repositorytype=JOBRESOURCE --no-deployed --local

# store items to JOC Cockpit rollout repository: object path and type of deployed or draft object
./deploy-git.sh store-item  "${request_options[@]}" --path=/TestRepo/51_JobTemplates/51_JobTemplate --type=JOBTEMPLATE

# store items to JOC Cockpit rollout repository: folder limited to draft objects
./deploy-git.sh getstore-item    "${request_options[@]}" --folder=/TestRepo --recursive

Storing Scheduling Objects to a Git Repository

The operation will update a Git repository to hold objects available in the JOC Cockpit inventory.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)request_options[@]}" --folder=/TestRepo --recursive --no-released --no-deployed

# store items to JOC Cockpit rollout respositoryrepository: folder limited to deployed objects
./deploy-git.sh store-item  "${request_options[@]}" --folder=/TestRepo --recursive --no-released --no-draft

# store items to JOC Cockpit rollout respositoryrepository: objectfolder pathlimited andto type of deployed objectreleased objects
./deploy-git.sh store-item  "${request_options[@]}" --pathfolder=/TestRepo/03_VariablesPassing/jdwVariablesAdHoc-repo --type=WORKFLOW --recursive --no-deployed --no-draft

# store items to local respository: object path and 

Deleting Scheduling Objects from a Git Repository

The operation will delete objects from JOC Cockpit's Git repository.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# delete items from JOC Cockpitrollout repository: foldertype of draft object
./deploy-git.sh store-item  "${request_options[@]}" --path=/TestRepo/03_VariablesPassing/jdjVariablesJobResource --type=JOBRESOURCE --no-deployed --local

# store items to rollout respository: object path and type of deployed or draft object
./deploy-git.sh storedelete-item  "${request_options[@]}" --path=/TestRepo/51_JobTemplates/51_JobTemplate" --type=JOBTEMPLATEfolder=/TestRepo/03_VariablesPassing

# storedelete items from JOC toCockpit rollout respositoryrepository: folderobject limitedpath toand draft objectstype
./deploy-git.sh storedelete-item  "${request_options[@]}"  --folderpath=/TestRepo/03_VariablesPassing/jdwVariablesAdHoc --recursive --no-released --no-deployedtype=WORKFLOW

# storedelete items from toJOC Cockpit rollout respositoryrepository: folderobject limitedpath toand deployed objectstype
./deploy-git.sh storedelete-item  "${request_options[@]}" --folder=/TestRepo --recursive --no-releasedpath=/TestRepo/51_JobTemplates/51_JobTemplate --no-drafttype=JOBTEMPLATE

# storedelete items from JOC toCockpit rolloutlocal respositoryrepository: folderobject limitedpath toand released objectstype
./deploy-git.sh storedelete-item  "${request_options[@]}"  --folderpath=/TestRepo/03_VariablesPassing/jdjVariablesJobResource --recursivetype=JOBRESOURCE --no-deployed --no-draft

...

local

Updating the JOC Cockpit Inventory from a Git Repository

The operation will delete objects from a Git Repositoryupdate JOC Cockpit's inventory from scheduling objects available in JOC Cockpit's Git repository.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# deleteupdate inventory items from JOC Cockpit rollout repository: folder
./deploy-git.sh delete update-item "${request_options[@]}" --folder=/TestRepo

# update inventory items from JOC Cockpit local repository: folder
./deploy-git.sh update-item "${request_options[@]}" --folder=/TestRepo --local

# update deleteinventory items from JOC Cockpit rollout repository: object path and object type
./deploy-git.sh deleteupdate-item "${request_options[@]}"  --path=/TestRepo/03_VariablesPassing/jdwVariablesAdHoc-repo --type=WORKFLOW

# delete items from rollout repository: object path and type
./deploy-git.sh delete-item "${request_options[@]}"  --path=/TestRepo/51_JobTemplates/51_JobTemplate --type=JOBTEMPLATE

# delete items from local repository: object path and type

Deploying Scheduling Objects from a Git Repository

The operation will update the JOC Cockpit's Git repository from inventory items and will push changes to the remote Git repository.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# store inventory items to JOC Cockpit rollout repository: folder
./deploy-git.sh deletestore-item    "${request_options[@]}"  --path=/TestRepo/03_VariablesPassing/jdjVariablesJobResource}" --typefolder=JOBRESOURCE/TestRepo --local

Updating the JOC Cockpit Inventory from a Git Repository

The operation will update the JOC Cockpit inventory from scheduling objects available in a Git repository.

# common options for connection to JS7 REST API
request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller)

# update items from rollout respository: folder
recursive

# add items to JOC Cockpit rollout repository
./deploy-git.sh add           "${request_options[@]}" --folder=/TestRepo

# commit changes to JOC Cockpit rollout repository and keep commit hash
hash=$(./deploy-git.sh update-itemcommit "${request_options[@]}" --folder=/TestRepo --folder=/TestRepomessage="v.1.23.34")

# updatepull itemschanges from local respository: folderremote repository to JOC Cockpit rollout repository
./deploy-git.sh update-item pull          "${request_options[@]}" --folder=/TestRepo --local

# updatepush itemschanges from rolloutJOC respository:Cockpit pathrollout andrepository typeto ofremote objectrepository
./deploy-git.sh update-itempush          "${request_options[@]}" --pathfolder=/TestRepo/03_VariablesPassing/jdwVariablesAdHoc-repo --type=WORKFLOW

Resources

• API
  • JS7 - REST Web Service API
  • JS7 - PowerShell Module
• Controller Status Operations
  • JS7 - Unix Shell CLI for Controller Status Operations
• Controller Deployment Operations
  • JS7 - Unix Shell CLI for Controller Deployment
• Workflow Deployment Operations
  • JS7 - Unix Shell CLI for Workflow Deployment
• Workflow Status Operations
  • JS7 - Unix Shell CLI for Workflow Status Operations
• Identity Service Deployment Operations
  • JS7 - Unix Shell CLI for Identity Service Deployment
• JOC Cockpit Status Operations
  • JS7 - Unix Shell CLI for JOC Cockpit Status Operations

...