GIT Support (4.3)
- Jenni Wallin
The following section provides information how Git is used to handle different system export scenarios when Git is used as a remote target.
How Git is working in our product
Git is a distributed version control system, more about Git can be read here. Usage Engine only supports connecting to a remote repository that is accessible with an HTTP/HTTPS URL and a Token. When the File System Profile of type Git is saved, a clone of the Repository is created in a directory in the Platform pod. This directory is $MZHOME/gitrepos by default. It can be changed by setting the property mz.git.basePath to some other path accessible from the Platform. Each File System Profile will have its own directory with its own clone of the corresponding repository.
The local copy of the repository is only updated to match the remote repository when these events occur:
An import is performed
A user clicks the “Refresh” button in the System Importer.
After an export is performed, regardless of if it is successful or failed.
When an export is performed to Git the system will:
Delete all files in the selected target folder
Perform an export to the selected folder
Commit the changes to the local repository
Push the commit to the remote repository
This means that even if just a few configurations have been updated a full export of what was in target folder from before needs to be made in order not to lose files in the repository version.
During step 4, when the export is pushed to the remote repository, Git can detect if the target folder on the remote repository is updated compared to the local target folder. If an update on the remote repository is detected, the system will evaluate if it will cause any conflicting scenarios (described below).
So, if the local repository is updated before an export (events described above) i.e. the local repository has the same status as the remote the system will not detect any conflict, and the system will overwrite the content in the target folder.
Recommendations for structuring of configuration
The structure of the folders in the Git repository is not decided by the system. Several developers working in parallell on the same deployment calls for structured configuration in order to avoid too many merge conflicts. The recommendation therefore is to have a separate folder in the Git repository for each use case.
Export Scenarios
When exporting configurations to Git multiple scenarios can happen because the remote repository is updated by another System or person. Different scenarios are described below.
Update in different directory
When there has been updates to any other target folder in the same repository the export will be successful.
Updated configurations in the same export folder, no conflict
When there has been updates in the remote repository to Configurations on other places than current System have modified in the same export folder the System Export will fail. The System Exporter will perform an Import of the Configurations that was changed on remote. They will be imported with a suffix named _merge. The action needed by you now is:
Move the change from the imported configurations to your local version of the same configurations. Then remove the configurations with the suffix.
Alternatively you can remove your local version and rename the imported version to the same name as before if there has not been any updates to the local version.
The Imported configuration with Suffix will have a different so called Key than the original. So if the Key is important for any other configuration referring to the configuration in question, or for the configuration itself you need to do the first option. This means that it is always recommended that in these cases the local version is retained whenever possible.
Example: If the configuration is an Aggregation Profile with File Storage then the Aggregation Storage directory on disk is based on the Key of the Profile.
When the actions mention above is performed a new export can be executed.
Update same configuration in the same Git Directory
When there has been updates in the remote repository to the same Configurations as the current System have modified in the same target folder the System Export will fail. The System Exporter will perform an Import of the conflicting Configurations. They will be imported with a suffix named _conflict. The action needed by you now is:
Move the change from the imported configurations to your local version of the same configurations. Then remove the configurations with the suffix.
When the actions mention above is performed a new export can be executed.
Configuration added, removed or renamed on Git in same Git Directory
The scenarios when configurations is added and removed or renamed will look the same during an export. Configurations that are added in the same export folder by any other system will be imported with the suffix of _added. Actions need by you is:
Rename the configurations with suffix _added, by removing the suffix.
Configurations that are removed in the same export folder by any other system but exist in current system will be copied to a new configuration with suffix _removed. Actions need by you is:
Remove the configurations with suffix _remove and the local configuration (if it shall be removed) with the same name but without the suffix.
When the actions mention above is performed a new export can be executed.