System ConfigurationIn order to store applications in a Git Repository, the a Git Repos Location must be set. A default value is populated for all new and upgraded systems. If your system has no value, follow the below steps to set this. - In PhixFlow, from the
Insert excerpt |
---|
| _administration |
---|
| _administration |
---|
nopanel | true |
---|
| menu, open System → Insert excerpt |
---|
| _system_config |
---|
| _system_config |
---|
nopanel | true |
---|
|
- In the System Directories section, enter a value for Git Repos Location,e.g. ${export_loc}/../git/
- your changes
Git Repositories A new Git Repository Head object will be defined This will be visible in the full repository and is not owned by an application System administrators and people with appropriate Git permissions will be able to create/view/edit/delete them The following properties will be available Name (must be unique) Description Type - local or remote For remote repositories: Url Branch username Authentication type - password / key password key
Status - read only Status message - read only
StructureThe Git repository layout will be structured so that it facilitates manual code review and in as far as is sensible reflects the Phixflow Repository view The name of each export file will be <container_type>/<container_name>/<object_type>/<safe_name>-<UID>.xml container_type: Application or Package container_name: Name of the container - is guaranteed to be unique in the system object_type: Type of the object, as displayed on property editors/repository (not the class name) safe name: Object name, sanitized so that it is filename safe UID: object UID to ensure all filenames are unique.
Handling of special characters such as '/' in container names should be tightened up to ensure generated names are safe The contents of the files will be compatible with the ImportFileService If an object has been deleted then it should be deleted from the repository If an object has been renamed then the original file should be deleted and the new file created Typically Git's rename detection will identify this as a rename
Creating a New Git RepositoryWhen a new local repo is first saved The directory ${gitrepo_loc}/${name} will be created It will be initialized as a new empty git repo with a single branch with a default name (configurable via properties, ‘main’) The branch will be checked out. The data will be persisted in the database The status will be set to Synced Failure to create the directory/perform the local git operations should result in an error without the object being persisted.
If a repo is renamed then The local directory will be renamed on disk The data will be persisted in the database Failure to rename the directory/perform the local git operations should result in an error without the object being persisted.
It is not permitted to change the type of a local repository When a remote repo is first saved The directory ${gitrepo_loc}/${name} will be created It will be initialized as a new remote tracking repository
The data will be persisted to the database The status will be set to Pending Failure to create the directory/perform the local git operations should result in an error without the object being persisted.
If any of the remote specific settings are change the status will be set to Pending If a repository is deleted the contents on disk should also be deleted A suitable warning message should be displayed before deleting a repository For local repositories this should stress it will permanently delete the files. For remote repositories it should be clear this will delete local files but will not modify the remote repository.
A test button will be available next to the settings of remote repository This will trigger a synchronous operation to attempt to connect to the remote url with the given credentials A result message should be returned indicating the error or success.
A sync operation will be available next to the status, this operation will also be triggered before an export or import. On local repositories this will revert any local changes to the git repo git checkout -f -B <branch>
On a remote repository this will Connect to the remote repository and fetch Reset the specified branch replacing any local changes
Status should be updated to synced with an appropriate message if it succeeds On failure an error should be shown indicating the cause and the status and message updated.
Configuration ExportFor users with appropriate permissions the configuration export screen will give the option whether to export to file or to Git. Exporting to Git will allow selection of a configured Git Repo The system will ensure only a lock is taken so only a single process can be exporting/importing from the Git repository at a time. Before export starts a sync will be performed and any errors reported. The exported directory structure must be in a form that is understandable to users manually looking at the Git change log or history. The author of the commit will be generated in the form “FirstName LastName <email>” of the active user The description will be used as the base commit message The export process will write (and deleted) files with the appropriate names and contents to the local git repository For remote repositories a push will be performed to update the remote repository with the changed files. Full and partial exports will be supported as with current file behaviour The export task log will include the Git target url, branch and commit hashes of the export.
Configuration ImportFor users with appropriate permissions the import export screen will give the option whether to import a file or from Git. Importing from Git will allow selection of a configured Git Repo The system will ensure only a lock is taken so only a single process can be exporting/importing from the Git repository at a time. Import from Git will always use the full contents of the remote branch for the import Protect on import settings will be honoured.
A sync operation will be used before the import The contents of the local git repo will be loaded and used for the import operation. It is an error if the branch does not exist or if the branch does not contain a valid export
The import task log will include the Git target url, branch and commit hashes of the import.
SecurityIn phase 1 Git repositories should only be usable by administrators, users must also have the relevant import/export permissions In later phases separate permissions should exist to create new Git Repositories, and User group base security determining who can update/delete the configuration, import from (read) or export to (write) each Git repository. In addition standard import/export permissions are required. By default repositories should be private, owned by the creator.
Repository passwords and private keys should be handled as local secrets
|