Git Provider

litmus edge manager (lem) support s native integration with git providers such as github, gitlab and azure devops this integration enables organizations to manage edge templates using standard git workflows, ensurin g version control, auditability, and centralized governance the git provider integration allows lem to store and version template files in a git repository automatically synchronize template updates of edge devices to git track template changes across companies and projects maintain a consistent configuration baseline across distributed deployments this diagram shows how template synchronization occurs from edge devices to lem and to your git provider the current implementation operates in one directional manner and is intended primarily for audit and tracking purposes prerequisites the configuration requires administrative access to litmus edge manager admin console a valid ssh git url (for example, git\@github com\ org/repo git) an ed25519/rsa sha2 512 public key generated by lem a deploy key with write access added to the git repository synchronization model lem supports the following synchronization mechanisms synchronization on a schedule hourly daily at 00 00 utc weekly on monday at 00 00 utc monthly on the 1st at 00 00 utc synchronization triggered during edge device backup synchronization that you triggered manually error handling and validation lem performs validation and provides actionable error messages for valid ssh keys whether the repository is accessible write permissions template schema compliance detecting sync conflicts security considerations authentication uses ed25519/rsa sha2 512 ssh keys deploy keys are scoped to a single repository write access is required in the git provider for lem to commit changes no credentials beyond the ssh keypair are stored best practices use a dedicated private repository for edge templates restrict deploy key permissions to the minimum required scope apply branch protection rules for production environments use scheduled sync for predictable updates use manual sync for validation and testing configuration workflow the following workflow shows how you set up git provider note also see the docid\ lrbapabg jke futaxf j setup a github repository in github, create a new private repository record the repository name configure git provider in lem in lem, navigate to integration > git provider select the git provider (github, gitlab, or azure devops) enter the ssh url from the private repository that you created with the following syntax git\@github com\ github name/github repo git copy the generated ssh public key add the public key to the repository for example, in github add the public key to the git repository as a deploy key with write access in lem, validate access to the repository confirm that the repository access successful message displays save the configuration configure project tracking you set tracking at the project level navigate to edge devices > edge git integration set the synchronization frequency hourly, daily, weekly, or monthly syncs occur at 00 00 (utc) daily, weekly on mondays, and monthly on the first day of the month for each company and project, choose when syncs occur to set syncs based on the synchronization frequency that you set, select track when the device is backed up, select sync on backup to run the synchronization manually, select run manual sync from the actions menu configure integration for edge devices at the company and project level in project tracking view the number edge devices and synced devices, last sync and commit id, and integration status the following columns display in project tracking field description company company to which the devices belongs project project to which the devices belong track enable to push changes to git based on the selected synchronization frequency sync on backup enable to push changes to git when the device is backed up edge devices number of devices in the project synced devices number of devices that have been synchronized last sync time the last time that a synchronization was performed from all edge devices in the current project to lem last commit git commit hash which is a unique identifier representing a specific commit in a git repository status status of the integration new , waiting , running , canceling , success , error , or cancel action options to enable or disable tracking on the predefined schedule, on device backup, or to run a manual synch