When the user runs the WhereScape GIT Enablement Pack, this will start the process of connecting to GIT and building the WhereScape 3D and RED repositories.

This should be done at the following times: 

  1. When connecting to a new GIT repository. 
  2. When connecting to an existing GIT repository for the first time (on a Developer machine). 
  3. When refreshing a Personal Access Token to an existing GIT repository. 
  4. When rebuilding a corrupted Developer machine's GIT repository. 

When the process is launched, it will prompt the user for the following information:

If the user requires to connect to a new or different GIT repository, these steps should be repeated using the new settings.

A GIT repository must exist before this process can start. 

A log file will be created and stored within the specified directory each time this process is executed. If there are any issues during this operation, the log file will be presented to the user for review. The log file can also be consulted to investigate steps taken as part of any interaction with the GIT Enablement Pack.

If this process is repeated for an existing GIT repository that has already been set up on the Developer machine, any changes not committed to GIT will be lost.

Changing the Repository Database Name

When completing the WhereScape GIT Enablement Pack form, the RED and 3D Repository Database names are read-only and are created based on the user information provided elsewhere on the form. However, this can be changed via the config file if required. 

  1. The config is held in a JSON file named 'config.json' at the following location: 
     %USERPROFILE%\WhereScape\GIT 
  2. The repository database names are calculated within their resepective RED or 3D sections under the 'Repository Database name prefix and suffix' keys. These values can be amended to change the way that the repository database names are created when completing the WhereScape GIT Enablement Pack from. 

WhereScape 3D

By default, WhereScape 3D and RED store their metadata in separate PostgreSQL databases. To make sure both applications stay in sync, GIT is used as the master source for all metadata. 

When developers pull the latest metadata files from the remote GIT repository, their local WhereScape repositories are rebuilt using those files. This keeps everything aligned to the same version (called a commit ID) and ensures consistency across both tools. 

This process has been designed to ensure that both WhereScape repositories are always aligned. 

Using WhereScape 3D Workflows

The below lists all avaialable Workflow processes in the WhereScape GIT Enablement Pack. All existing WhereScape 3D workflow processes remain available.

To configure your workflows, please consult section ‘Configuring Workflows’.

Committing to GIT

To commit a new model or changes to an existing model to GIT, users click the workflow button, which executes the ed3d_commit_to_git template.

This workflow is used for the following reasons:

  1. After making a change to a new data model.
  2. After making a change to an existing data model.

This workflow will perform the following tasks:

  1. Verifies connection to GIT Repository.
  2. Brings in the latest changes from the remote repository so your local setup is up to date.
  3. Saves the current version of your local repository.
  4. The user will be prompted to add their own commit message:
  5. Commits your changes to the remote GIT repository with your message.

A log file will be created and stored within the specified directory each time this workflow is executed. If there are any issues during this operation, the log file will be presented to the user for review.

Users can create/change the workflow configuration for any category, model, or model version; however, this function requires the user to select the model version to operate correctly.

Only create a “Commit to GIT” button within a workflow for use at the Model Version level.

Any changes to workflows or categories will require a separate commit action; see committing configuration changes to GIT.

Committing ALL Objects to GIT

To commit all changes made to a WhereScape 3D Repository, users click the workflow button, which executes the ed3d_commit_all_objects_to_git template.

This workflow is used for the following reasons:

  1. After making changes to multiple new and/or existing data models.
  2. After making changes to data models and configuration.

This workflow will perform the following tasks:

  1. Verifies connection to GIT Repository.
  2. Brings in the latest changes from the remote repository so your local setup is up to date.
  3. Saves the current version of your local repository.
  4. The user will be prompted to add their own commit message:
  5. Commits all your changes to the remote GIT repository with your message.

A log file will be created and stored within the specified directory each time workflow is executed. If there are any issues during this operation, the log file will be presented to the user for review.

Committing configuration changes to GIT

To commit any configuration changes to GIT, users will click the workflow button, which executes the ed3d_commit_config_to_git template.

This workflow is used for the following reasons:

  1. After creating a new configuration setting.
  2. After deleting an existing configuration setting.
  3. After changing an existing configuration setting.

This workflow will perform the following tasks:

  1. Verifies connection to GIT Repository.
  2. Brings in the latest config changes from the remote repository so your local setup is up to date.
  3. Refers to the GIT Audit Change log within the WhereScape 3D repository.
  4. Extracts the configuration files & stores them within the local GIT repository folder.
  5. The user will be prompted to add their own commit message:
  6. Commits the config change to the remote GIT repository with your message.

A log file will be created and stored within the specified directory each time this workflow is executed. If there are any issues during this operation, the log file will be presented to the user for review.

It is recommended that a “Commit Config to GIT” button be created within a workflow for use at the Category level.