Page History
...
- 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 , see for JS7 - Rollout of Scheduling Objects. See the scenarios and use cases from in the JS7 - Git Repository Interface article.
- The sections below sections 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 along with the following iterationsJS7 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 forrollout
to subsequent environments such as in a sequence dev = -> test = -> prod. For details see JS7 - Git Repository Interface, chapter: Configuration Scheduling Object Mappings. - For Settings for each scheduling object type settings determine if this whether it should be considered for
local
use or forrollout
to a remote Git repository:git_hold_workflows
: see JS7 - Workflowsgit_hold_resource_locks
: see JS7 - Resource Locksgit_hold_file_order_sources
: see JS7 - Job Resourcesgit_hold_notice_boards
: see JS7 - Notice Boardsgit_hold_script_includes
: see JS7 - Script Includesgit_hold_job_resources
: see JS7 - Job Resourcesgit_hold_calendars
: see JS7 - Calendarsgit_hold_schedules
: see JS7 - Schedules
Git Repositories
JS7 configuration scheduling objects are transparently managed in a Git repository via the JOC Cockpit GUI that makes use of 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
sub-folders of the JETTY_BASE/resources/joc/repositories
folder folders. Each roottop-level folder in the JS7 Configuration view JOC Cockpit inventory can be mapped to a Git repository.
- The local repository for a JS7 roottop-level folder is created when a user performs the
checkout
orclone
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 by use of using the Git
push
operation. - The JS7 - Cleanup Service removes any local repositories if the JS7 roottop-level folder no longer exists, i.e. if a roottop-level folder is dropped from JOC Cockpit.
Basic Inventory Operations
- was dropped from JOC Cockpit.
The JOC Cockpit can be used to interface with remote Git repositories to store and rollout scheduling objects such as workflows and jobs.
- The JOC Cockpit supports use of Git compliant servers to manage remote repositories such as GitLab, GitHub.
- 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 Any inventory operations are based on root top-level folders that are mapped to Git repositories, see JS7 - Git Repository Interface, chapter: Folder Mappings. Inventory operations do not require a Git Client but are performed directly by JOC Cockpit.
The JOC Cockpit GUI offers provides the Repository action menu Repository to select for selecting objects for local and rollout repository use like thisas shown in the diagram below:
Operations offered by the above The operations available in the action menu items are explained with described in the following chapterssections.
Store Objects to local Repository
This operation is performed to store stores objects managed with the JOC Cockpit database to in the file system that 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 like thisas shown in the next screenshot:
When storing objects intended for rollout to other environments via the Repository=->Rollout=->Store to repository action then a popup window is displayed like thisas shown here:
Explanation:
- Filter
- Filters can be applied to select Draft only draft objects only 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 for example including workflows, job resources etc.
- Objects released within JOC Cockpit include for example calendars and schedules.
- Filters can be applied to select Draft only draft objects only or objects that have been deployed or released.
- Handle recursively
- This The checkbox allows to select from a root level folder any included selection of a top-level folder to include any sub-folders and objects.
- Tree
- The tree allows to navigate 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 chapter the Settings section.
- The tree allows to navigate navigation of included folders and objects for selection. Individual selection Selection of individual objects requires the the
Update Objects from local Repository
This operation is performed to update updates scheduling objects in the JOC Cockpit database inventory from objects in the file system that 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 like thisas shown in the next screenshot:
When updating objects intended for rollout to other environments via the Repository=->Rollout=->Update from repository action then a popup window is displayed like thisas shown here:
Explanation:
- Handle recursively
- This The checkbox allows to select from a root level folder any included selection of a top-level folder to include any sub-folders and objects.
Tree
Object The object types offered, such as Workflows, Resource Locks etc., depend on the settings for the object type, : see chapter the Settings section.
Delete Objects from local Repository
This operation is performed to delete deletes objects from the file system that which holds the local Git repository.
When deleting objects local to the environment via the Repository=->Local=->Delete from repository action then a popup window is displayed like thisas shown in the next screenshot:
When deleting objects intended for rollout to other environments via the Repository=->Rollout=->Delete from repository action then a popup window is displayed like thisas shown here:
Explanation:
- Handle recursively
- This The checkbox allows to select from a root level folder any included selection of a top-level folder to include any sub-folders and objects.
Tree
Object The object types offered, such as Workflows, Resource Locks etc. depend on the settings for the object type, see chapter Settings.: see the Settings section.
Git Server Operations
Anchor | ||||
---|---|---|---|---|
|
Git credentials are managed from the user account's profile, see JS7 - Profiles - Git Management..
Anchor | ||||
---|---|---|---|---|
|
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.
The operation for cloning to an existing top-level folder is available from the relevant top-level folder using the Repository->Local|Rollout->Git->Clone action menu item like this:
The operation for cloning to a new top-level folder, starting from the root folder, '/' 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 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 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 specified.
After cloning, a popup window will present a feedback message like this:
After cloning, the tree in the left panel 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 Repository->Local|Rollout→Update from repository action menu has to be invoked like this:
Anchor | ||||
---|---|---|---|---|
|
Before pushing changes to a Git repository, such changes have to be stored to the local repository using 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 reflects scheduling objects that have been added, updated or removed. In addition, the changes are committed to the local repository staging area and require a message to be added by the user like this:
In response to the push operation a popup window will appear with a feedback message like this:
Anchor | ||||
---|---|---|---|---|
|
The Repository->Local|Rollout->Git->Pull action menu item is used to pull changes from a remote Git repository to the local repository as shown below:
In response to the pull operation, a popup window will appear with a feedback message like this:
The above message indicates that the local repository is up-to-date.
Further Resources
Display content by label | ||||
---|---|---|---|---|
|