Page History
...
- JS7 supports 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.
...
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 operations do not require a Git Client but are performed directly by JOC Cockpit.
...
- Handle recursively
- The checkbox allows selection of a top-level folder to include any sub-folders and objects.
- Tree
- The Object types offered, such as Workflows, Resource Locks etc. , depend on the settings for the object type: see the Settings section.
Git Server Operations
Manage Credentials for Git Access
Git credentials are managed from a 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.
For low and medium Security Levels the Profile view offers the Git Management tab like this:
When clicking the Git Management tab the list of available Git credentials is displayed like this:
When clicking on an entry and when clicking the button a popup window is displayed for management of credentials like this:
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.
- The location of the Private Key file can be specified like this:
- 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 to an existing top-level folder the operation is available from the respective top-level folder with the Repository->Local|Rollout->Git->Clone action menu item like this:
To clone 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:
Explanation:
- Git URL: The URL
git@github.com:sos-berlin/js7-demo-inventory-rollout-test.git
from the example includes the following parts:git@
: Thegit@
prefix is a constant value.github.com:
: The hostname and optionally port - separated by a colon - of the Git Server.sos-berlin/
: The owner account of the repository.js7-demo-inventory-rollout-test
: The name 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 has to be added.
After cloning a popup window presents a feedback message like this:
After cloning the tree in the left panel includes the top-level folder to which the repository has been cloned.
In order to populate the JOC Cockpit inventory top-level folder the Repository->Local|Rollout→Update from repository action menu has to be invoked like this:
Push to Git Repository
Before pushing changes to a Git repository such changes have to be stored to the local repository by use of the Repository->Local|Rollout->Store to repository 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 scheduling objects that have been added, updated or removed. In addition, the changes are committed to the local repository staging area and request a message to be added by the user like this:
In response to the push operation a popup window appears with a feedback message like this:
Pull from Git Repository
To pull changes from a remote Git repository to the local repository the Repository->Local|Rollout->Git->Pull action menu item is available.
In response to the pull operation a popup window appears with a feedback message like this:
The above message indicates that the local repository is up-to-date.
Further Resources
...