...

• The JS7 inventory holds scheduling objects such as JS7 - Workflows, JS7 - Calendars and Schedules etc. that are stored with the JS7 - Database.
• Users can integrate the JS7 inventory with Git repositories for JS7 - Rollout of Scheduling Objects. See the scenarios and use cases in the JS7 - Git Repository Interface article.
• The sections below explain the use of the operations for Git repositories that are available from the JOC Cockpit GUI. For automation see JS7 - How to rollout from test to prod environments in a CI / CD pipeline.
• Availability of Git integration is provided with the following JS7 releases:

  • Display feature availability
    StartingFromRelease 2.2.0

    • Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1216

    • Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1217

    • Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1144

  • Display feature availability
    StartingFromRelease 2.3.0

    • Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1218

    • Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1219

    • Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1213

    • Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1214

    • Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-1215

...

• Settings are used to determine which scheduling objects are considered local to an environment and which scheduling objects should be used for rollout to subsequent environments such as in a sequence dev -> test -> prod. For details see JS7 - Git Repository Interface, chapter: Scheduling Object Mappings.
• Settings for each scheduling object type determine whether they it should be considered for local use or for rollout to a remote Git repository:
  • git_hold_workflows: see JS7 - Workflows
  • git_hold_resource_locks: see JS7 - Resource Locks
  • git_hold_file_order_sources: see JS7 - Job Resources
  • git_hold_notice_boards: see JS7 - Notice Boards
  • git_hold_script_includes: see JS7 - Script Includes
  • git_hold_job_resources: see JS7 - Job Resources
  • git_hold_calendars: see JS7 - Calendars
  • git_hold_schedules: see JS7 - Schedules

...

JS7 scheduling objects are transparently managed in a Git repository via the JOC Cockpit GUI and using the JS7 - REST Web Service API. In addition, tools such as Git Extensions and Git command line clients can be used for repository operations.

The JOC Cockpit holds a number of local repositories inside the /local and /rollout subfolders sub-folders of the JETTY_BASE/resources/joc/repositories folders. Each top-level folder in the JS7 Configuration view JOC Cockpit inventory can be mapped to a Git repository. 

• The local repository for a JS7 top-level folder is created when a user performs the checkout or clone operation for the Git repository via JOC Cockpit.
• The local repository is persistent and is updated from the JOC Cockpit database (store inventory operation) and from the remote Git repository (pull Git operation).
• The remote Git repository is updated from the local repository using the Git push operation.
• The JS7 - Cleanup Service removes any local repositories if the JS7 top-level folder no longer exists, i.e. if a top-level folder has been was dropped from JOC Cockpit.

The JS7 JOC Cockpit can be used to interface with remote Git repositories to store and to rollout its scheduling objects such as workflows and jobs.

• JS7 The JOC Cockpit supports use of Git compliant servers to manage remote repositories such as as GitLab, GitHub.
• JS7 The JOC Cockpit makes use of a Git CLI Client that has to be provided by the user and has to be accessible to the run-time account of the JOC Cockpit daemon or Windows Service.

Inventory Operations

All inventory operations are based on top-level folders that are mapped to Git repositories, see JS7 - Git Repository Interface, chapter: Folder Mappings. Basic inventory Inventory operations do not require a Git Client but are performed directly by JOC Cockpit.

...

This operation stores objects managed with the JOC Cockpit database to in the file system which holds the local Git repository.

When storing objects local to the environment via the Repository->Local->Store to repository action then a popup window is displayed as shown in the next diagramscreenshot:

When storing objects intended for rollout to other environments via the Repository->Rollout->Store to repository action then a popup window is displayed as shown here:

...

• Filter
  • Filters can be applied to select only draft objects or objects that have been deployed or released.
    • Valid objects that match the schema for their object type.
    • Objects deployed to a Controller and to Agents include including workflows, job resources etc.
    • Objects released within JOC Cockpit include calendars and schedules.
• Handle recursively
  • The checkbox allows selection of a top-level folder to include any sub-folders and objects.
• Tree
  • The tree allows navigation of included folders and objects for selection. Individual selection Selection of individual objects requires the the Handle recursively checkbox to be unchecked.
  • The Object types offered, such as Workflows, Resource Locks etc., depend on the settings for the object type: see the Settings section.

Update Objects from local Repository

This operation updates scheduling objects in the JOC Cockpit database inventory from objects in the file system which holds the local Git repository.

When updating objects local to the environment via the Repository->Local->Update from repository action, then a popup window is displayed as shown in the next diagramscreenshot:

When updating objects intended for rollout to other environments via the Repository->Rollout->Update from repository action then a popup window is displayed as shown here:

...

• Handle recursively
  • The checkbox allows selection of a top-level folder to include any sub-folders and objects.
• Tree
• The Object object types offered, such as Workflows, Resource Locks etc., depend on the settings for the object type: see the Settings section.

...

When deleting objects local to the environment via the Repository->Local->Delete from repository action then a popup window is displayed as shown in the next diagramscreenshot:

When deleting objects intended for rollout to other environments via the Repository->Rollout->Delete from repository action then a popup window is displayed as shown here:

...

• Handle recursively
  • The checkbox allows selection of a top-level folder to include any sub-folders and objects.
• Tree
• The Object object types offered, such as Workflows, Resource Locks etc. depend on the settings for the object type: see the Settings section.

Git Server Operations

Anchor
git_access git_access

Manage Credentials for Git Access

Git credentials are managed from a the user account's profile.

Depending on the Security Level that JOC Cockpit is operated for the following applies:

• LOW: Git credentials are added to the default account, typically the root account.
• MEDIUM: Git credentials are added per user account.
• HIGH: Git credentials are not added to JOC Cockpit.

...

Image Removed

...

Image Removed

...

, see JS7 - Profiles - Git Management..

Anchor
git_clone git_clone

Image Removed

Explanation:

• Git Server: Credentials are managed per Git Server.
  • The Git Server entry has to be unique. Users can manage different credential sets for different Git Servers. Should different Git accounts be used for the same Git Server then different JOC Cockpit accounts have to be used.
  • The Git Server is specified from the hostname and optionally the port of the Git Server.
• Git Account, User Name, E-Mail Address: The Git Account has to be available with the Git Server, the User Name and E-Mail Address can be freely chosen.
• Authentication Type: This offers to use one of the following options:
  • Password: This authentication method is denied by a larger number of Git Servers.
  • Private Key: This authentication method makes use of Secure Shell (SSH) that is included with the Git Client.
    • The location of the Private Key file can be specified like this:
      • file name: JOC Cockpit creates the directory JETTY_BASE/resources/joc/repositories/private to which the private key file has to be stored by the user. JOC Cockpit will use this directory to identify the Private Key file and to authenticate with the Git Server.
      • empty file name: JOC Cockpit will use the Private Key file ~/ssh/id_rsa from the JOC Cockpit account's home directory.
      • path to a file: JOC Cockpit makes use of the indicated path to a Private Key file. The path has to be accessible to the JOC Cockpit Jetty servlet container.
    • Users have to manually store the Private Key file to the indicated location.
  • Access Token: This authentication method is considered similarly insecure as use of passwords and is not offered by all Git Servers.
    • The Access Token is created and is stored with the Git Server

Clone Git Repository

A Git repository can be cloned to a new top-level folder in the JOC Cockpit inventory and it can be cloned to an existing top-level folder.

To clone The operation for cloning to an existing top-level folder the operation is available from the respective relevant top-level folder with the using the Repository->Local|Rollout->Git->Clone action menu item like this:

To clone The operation for cloning to a new top-level folder, starting from the root folder, '/ the operation ' is available from the Repository->Local|Rollout->Git->Clone action menu item like this:

...

This brings up the following popup window:

Image Modified

Explanation:

• Git URL: The URL git@github.com:sos-berlin/js7-demo-inventory-rollout-test.git from the example includes the following parts:
  • git@: The git@ prefix is a constant value used for ssh access to the git server.
  • github.com: The hostname and optionally port - separated by a colon - of the Git Server.
  • :sos-berlin: The owner account of the repository - starting with a colon.
  • /js7-demo-inventory-rollout-test: The path of the repository.
  • .git: The .git suffix is a constant value.
• Git URL for HTTP(S) access: The URL https://github.com/sos-berlin/js7-demo-inventory-rollout-test.git contains similar parts.  
  • https://: The protocol to be used to access the git server (HTTP or HTTPS, if available).
  • github.com: The hostname and optionally port - separated by a colon - of the Git Server.
  • /sos-berlin/: The owner account of the repository - starting with a slash.
  • /js7-demo-inventory-rollout-test: The name path of the repository.
  • .git: The .git suffix is a constant value.
• Folder Name: The input field is available if the clone operation is invoked from the root folder '/' to clone to a new top-level folder. The name of the new top-level folder has to be addedspecified.

After cloning, a popup window presents will present a feedback message like this:

Image Modified

After cloning, the tree in the left panel includes will include the top-level folder to which the repository has been cloned.

In order to populate the JOC Cockpit inventory top-level folder the , the Repository->Local|Rollout→Update from repository action menu has to be invoked like this:

Anchor
git_push git_push

Push to remote Git Repository

Before pushing changes to a Git repository, such changes have to be stored to the local repository by use of the using the Repository->Local|Rollout->Store to repository action action menu item.

To push changes to scheduling objects from a local repository to the remote Git repository the Repository->Local|Rollout->Git->Push action menu item has to be invoked like this:

The push operation includes to reflected reflects scheduling objects that have been added, updated or removed. In addition, the changes are committed to the local repository staging area and request require a message to be added by the user like this:

Image Modified

In response to the push operation a popup window appears will appear with a feedback message like this:

Image Modified

Anchor
git_pull git_pull

Pull from remote Git Repository

To pull changes from a remote Git repository to the local repository the The Repository->Local|Rollout->Git->Pull action menu item is available.used to pull changes from a remote Git repository to the local repository as shown below:

In response to the pull operation a operation, a popup window appears will appear with a feedback message like this:

Image Modified

The above message indicates that the local repository is up-to-date.

...