This space contains documentation for TrueSight Server Automation 8.9.03 and the later service packs for 8.9. For earlier releases, see BMC Server Automation 8.9.

Setting up Git repositories

To enable version management of component templates and Network Shell scripts, you can set up an integration between TrueSight Server Automation and Git repository tools (including GitHub, Gitblit, and GitLab). For the Git integration you must set up a local repository in the TrueSight Server Automation environment, as well as the remote Git repository. Changes that you introduce into TrueSight Server Automation objects are first committed into the local repository, and later pushed to the remote Git repository.

Note: Reverting a Git integration

You cannot undo a Git integration once you have configured it.

The local repository has the following requirements:

  • Must reside on a computer that hosts an RSCD agent, preferably on the file server.
  • Not located behind a SOCKS proxy server.
  • (For Windows only) Git Bash version 1.8 or above installed. (You can download the Git Bash for Windows here.)
    If installing Git Bash version 2.7.4 or later on Windows, do not enable the Git Credential Manager.
  • Minimum disk space: 2 GB
  • Minimum memory: 1 GB of RAM


 For information about setting up your remote Git repository, refer to the documentation of your Git repository tool. For example:

  • Creating a GitHub repository
  • Setting up a GitBlit repository
  • Creating a GitLab project

To configure TrueSight Server Automation with a GIT repository, use the Git saveGitConfig BLCLI command.

To configure Git repositories

  1. Select Configuration > Infrastructure Management.
  2. In the Infrastructure Management window, right-click Git Repository and select Git Repository Configuration.
  3. In the Git Repository Setup dialog box, on the Local Repo Details tab, enter the following information about the local repository:

    Repository ServerThe name or IP address of the computer that hosts the local repository, a clone of the remote Git repository.
    Repository Path

    The path to the local repository, in NSH format.
    For example: /C/git_local_repo

    If you use this field to set a new location for a local repository that you have already configured, note the following points:

    • You cannot revert to an existing, non-empty path. If you want to reuse a path, first delete the old directory of the path, if it still exists.
    • A new Validate tab appears, prompting you to commit any uncommitted changes and to push committed changes to the remote Git repository. See step 5.
    Git Installation LocationFor Windows only: The path to the folder that contains the Git bash, typically C:\Program Files\Git\bin.
    Email Domain

    The email domain to use to generate email IDs of logged-on users.

    In the case of users that are logged on with an authentication profile that is based on an authentication method of AD/Kerberos or Domain Authentication, if the user name includes the at sign (@), the email domain that you define through this setting overrides the domain specified after the @ sign in the user's name. For example, if the user name is and the email domain that you specify here is, then the email address that will be used as an identifier for Git commits is

  4. On the Remote Repo Details tab, enter the following information about the remote Git repository:

    1. In the Repository URL field, specify the URL for the Git repository, as obtained from your Git repository tool.
      This URL is used to perform an initial cloning of the remote Git repository and to initiate it for use by the local repository.
      The exact format of the URL depends on the Git repository tool. For example:

      • GitBlit: https://server:port/r/repoName.git

      • GitHub: https://github.domain/user/repoName.git

      • GitLab: https://server/root/repoName.Git


      You can use this field to switch to a new remote Git repository. In such a case, before setting a new repository URL, manually clone the Git repository to the new location. By doing so, you ensure that existing data (already stored in the repository) is not lost.

    2. Specify an automation principal that has the proper credentials for access to the Git repository. You can choose between the following options:

      OptionAdditional information to enter
      Select an existing automation principalName of the existing automation principal

      Note: Ensure that the automation principal that you specify is not configured to use a private key for authentication.
      Create a new automation principalAutomation principal credentials — user name, password, and domain
    3. If the Git repository is hosted with a self-signed SSL certificate, clear the SSL Verify check box, so that the SSL handshake does not fail.
  5. If you changed the name or location of an existing local repository (through the Repository Server or Repository Path fields in step 3), you must commit uncommitted changes and push changes to the remote Git repository before all data from the existing local repository is migrated to the new local repository. The Validate tab lists the changes that need to be committed and pushed.
    On this tab, enter a commit message in the Commit Message field and then click Commit and Push ALL.
  6. Click Save.
    Git repository details appear in the Infrastructure Management window on the right when the Git Repository branch is selected on the left.

Was this page helpful? Yes No Submitting... Thank you


  1. Matthias Weidinger

    Is there any way of storing BLPackages in GitHub e.g. BLPackge to deploy Notepad++?

    Oct 30, 2019 11:00
    1. Ranu Ganguly

      Thank you for your comment. I will check and revert.

      Oct 31, 2019 02:13
    1. Bipin Inamdar

      Hi Matthias,

      The R&D team says that there is no way of storing BLPacakages in GitHub. It is used for NSH scripts and not for BLpackages.

      Jul 05, 2020 04:04