Page History

...

• For JS7 - Rollout of Scheduling Objects, the JOC Cockpit can be used to interface with Git repositories in order to store and rollout scheduling objects such as workflows and jobs.
  • JS7 supports the use of Git compliant servers to manage remote repositories such as GitLab, GitHub.
  • JS7 makes use of a Git CLI Client that has to be provided by the user.
• Scheduling objects can be versioned (tagged) with Git and can be rolled out to different JS7 environments via Git. This allows the creation and testing of workflows in a development environment and  rollouts to a production environment to be performed using a Git repository.
• A connection to a Git repository is considered an additional option for managing versions and rollouts of JS7 scheduling objects.
• For operations available from the JOC Cockpit GUI see JS7 - Inventory Git Integration. For automation see JS7 - How to rollout from test to prod environments in a CI / CD pipeline.
• The Git Repository Interface is made available with the following JS7 releases:

  • Display feature availability
    StartingFromRelease 2.3.0

     
  • Release 2.3.0: Make JS7 objects available from the file system to allow use of external Git tools.

    • 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

  • Release 2.4.0: Enable JOC Cockpit to manage JS7 objects with Git.

    • 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

...

• Folders hold scheduling objects such as workflows etc. and any level of sub-folders.
• Folders are the basic unit for JS7 - Default Roles and Permissions. For example, users can be granted access only to specific folders.
• Folders allow bulk operations such as deploying, releasing, and removing and the renaming of scheduling objects to be performed.

Folders can be mapped to Git repositories managed by the same or by different Git servers Servers like this:

USER1 [label="User: 1",fillcolor="lightskyblue",fontname="Arial",fontsize="10pt"]
USER2 [label="User: 2",fillcolor="lightskyblue",fontname="Arial",fontsize="10pt"]
USER3 [label="User: 3",fillcolor="lightskyblue",fontname="Arial",fontsize="10pt"]

FOLDER1 [label="Folder: 1",fillcolor="white",fontname="Arial",fontsize="10pt"]
FOLDER1a [label="Sub-folder: 1.1",fillcolor="white",fontname="Arial",fontsize="10pt"]
FOLDER1b [label="Sub-folder: 1.2",fillcolor="white",fontname="Arial",fontsize="10pt"]
FOLDER2 [label="Folder: 2",fillcolor="white",fontname="Arial",fontsize="10pt"]
FOLDER3 [label="Folder: 3",fillcolor="white",fontname="Arial",fontsize="10pt"]

REPOSITORY1L [shape="ellipse",label="Repository: 1-local\njob resources etc.",fillcolor="darkolivegreen1",fontname="Arial",fontsize="10pt"]
REPOSITORY1R [shape="ellipse",label="Repository: 1-rollout\nworkflows etc.",fillcolor="darkolivegreen1",fontname="Arial",fontsize="10pt"]
REPOSITORY2L [shape="ellipse",label="Repository: 2-local\njob resources etc.",fillcolor="darkolivegreen1",fontname="Arial",fontsize="10pt"]
REPOSITORY2R [shape="ellipse",label="Repository: 2-rollout\nworkflows etc.",fillcolor="darkolivegreen1",fontname="Arial",fontsize="10pt"]
REPOSITORY3L [shape="ellipse",label="Repository: 3-local\njob resources etc.",fillcolor="darkolivegreen1",fontname="Arial",fontsize="10pt"]
REPOSITORY3R [shape="ellipse",label="Repository: 3-rollout\nworkflows etc.",fillcolor="darkolivegreen1",fontname="Arial",fontsize="10pt"]

USER1 -> FOLDER1 [label="  can access  ",fontname="Arial",fontsize="10pt"]
USER2 -> FOLDER1 [label="  can access  ",fontname="Arial",fontsize="10pt"]
USER2 -> FOLDER2 [label="  can access  ",fontname="Arial",fontsize="10pt"]
USER3 -> FOLDER3 [label="  can access  ",fontname="Arial",fontsize="10pt"]

FOLDER1 -> FOLDER1a [label="  includes  ",fontname="Arial",fontsize="10pt"]
FOLDER1 -> FOLDER1b [label="  includes  ",fontname="Arial",fontsize="10pt"]
FOLDER1a -> REPOSITORY1L [label="  maps to  ",fontname="Arial",fontsize="10pt"]
FOLDER1a -> REPOSITORY1R [label="  maps to  ",fontname="Arial",fontsize="10pt"]
FOLDER1b -> REPOSITORY1L [label="  maps to  ",fontname="Arial",fontsize="10pt"]
FOLDER1b -> REPOSITORY1R [label="  maps to  ",fontname="Arial",fontsize="10pt"]

FOLDER2 -> REPOSITORY2L [label="  maps to  ",fontname="Arial",fontsize="10pt"]
FOLDER2 -> REPOSITORY2R [label="  maps to  ",fontname="Arial",fontsize="10pt"]
FOLDER3 -> REPOSITORY3L [label="  maps to  ",fontname="Arial",fontsize="10pt"]
FOLDER3 -> REPOSITORY3R [label="  maps to  ",fontname="Arial",fontsize="10pt"]

...

• user access:
  • users with JS7 access permissions to manage folders and to access the Git repository can manage scheduling objects in the JOC Cockpit and can commit, push, pull scheduling objects to/from Git,
  • users with JS7 access permissions to manage folders but without access to the Git repository can manage scheduling objects in the JOC Cockpit,
  • users with JS7 access permissions to view folders do not require Git access.
• folder usage:
  • if a single Git repository should be used then all folders have to be available from a single top-level folder,
  • for use with a number of Git repositories each top-level folder maps to a different repository,
  • folders can remain without Git integration for local management and deployment.

JOC Cockpit maps top-level folders to Git repositories and stores the relevant Git repository URL for each folder in its inventory.

...

The following credentials are manged managed depending on the Git serverServer's authentication method:

• Git Server
  • host(:port) of the remote Git Server
• Git Account
  • account that is used to connect to a Git server
• User name
  • name used as author name e.g. for commits
  Email
• E-Mail
  • email mail address used as author email address e.g. mail address, for example for commits
• password
  • the user's password for httpHTTP(sS) Git access
• private key
  • the path to the user's private key file for ssh SSH Git access
• Access Token
  • the access token for httpfor HTTP(sS) Git access

If repositories are used from a number of Git serversServers, that require different sets of user credentials, then this can be manged managed within one JOC Cockpit account, Only one set of credentials per Git Server is used.

If repositories are used from the same Git servers Servers that require different sets of user credentials then separate user accounts in JOC Cockpit have to be used.

...

• The local repository for a JS7 top-level folder is created when a user performs the clone operation for the Git repository via the JOC Cockpit.
• The local repository is persistent and is updated from the JOC Cockpit database (store operation) and from the remote Git repository (pull operation).
• The remote Git repository is updated from the local repository by use of the 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 dropped from the JOC Cockpit.

The following REST Web Service API operations are available:

• ./inventory/repository/git/checkout
  • checks out a specific branch or tag from the Git repository to the local repository
• ./inventory/repository/git/clone
  • initially clones a Git repository to a local repository
• ./inventory/repository/git/add
  • adds or updates (stages) all new or modified scheduling object on the file system to the local repository
• ./inventory/repository/git/commit
  • commits all staged scheduling objects to a local repository
• ./inventory/repository/git/push
  • pushes changes from the local repository to the remote Git repository

...

• git-tag
  • JS7 REST Web Service API not implemented yet
  • tags a commit with a version label
• ./inventory/repository/git/push
  
  • see above

...

The following operations are available:

• ./inventory/repository/git/checkout
  
  • checks out a specific branch or tag on the local repository
• ./inventory/repository/git/clone
  • initially clones a remote repository to a local repository
• ./inventory/repository/git/pull
  • pulls recent changes from the remote repository to the local repository

...

The following JS7 REST Web Service operations are available:

• ./inventory/repository/read
  • reads the file tree of the local repository file system folder and updates the JOC Cockpit database
• ./inventory/repository/store
  • stores a set of scheduling objects from the JOC Cockpit database to the file system folder of the local repository
• ./inventory/repository/delete
  
  • deletes a set of scheduling objects from the file system folder of the local repository
• ./inventory/repository/update
  
  • adds or updates a set of scheduling objects in the JOC Cockpit database with scheduling objects from the local repository's file system folder

...

• from the JS7 - PowerShell Module, see PowerShell CLI 2.0 - Use Cases - CI/CD Pipeline AutomationJS7 - How to rollout from test to prod environments in a CI CD pipeline.
• from any scripting language that supports a REST Client, executing curl from a shell script might be sufficient.
• Operations can be performed on any platform, no direct access to the JS7 production environment is required, however, credentials have to be provided to connect to the JS7 REST Web Service API.

...