Skip to main content
Version: 7.8

Git Synchronization

Introduction​

Git Synchronization feature gives the ability to distribute runbooks and action tasks content across Resolve Actions Pro instances which are not connected in a cluster, as well as content distribution between the local development environment and the Actions Pro instances.

Enabling the feature 

  • Simplifies the deployment process and remote content sharing without the need to transport the file manually – reduces the human error factor.
  • Leverages a central repository to persist and store content
  • Enables developers to develop in IDE of their choice and synchronize the changes back in Actions Pro.
  • Enables concurrent development in Actions Pro and scheduled content synchronization.

The following document describes Git Synchronization of runbooks and action tasks of Actions Pro.

Terminology​

The following terminology is used within the document:

  • Runbook – (Actions Pro - specific term) - an orchestrated set of tasks composed to achieve a unit of work(fully), the runbook is implemented using Automation Model
  • Automation - (Actions Pro - specific term) - Actions Pro is a collaborative process automation platform which core concept is the Runbook. A Runbook is the way to do automation in Actions Pro, so they seem to be used very often interchangeably. It includes guided procedures and interactive automations that enable IT operations staff, system administrators, developers or process experts to streamline incident/repair, configuration, and provision processes.
  • Action Task - (Actions Pro - specific term) - components that are performing various steps оr parts of the overall work, they are executable components such as program or script. Actions Pro Automation unit that encapsulates a defined set of commands used on a local system or RSremote
  • Version – a current state of a runbook (automation) or an ActionTask

Reference to Other Documentation​

For detailed information about how to create runbooks, see Automation Designer Guide and Action Task Development Guide.

Getting Started​

Overview​

In this document we describe:

  1. how to synchronize the content of runbooks and action tasks among Actions Pro instances which are not connected in a cluster
  2. how to synchronize the content of runbooks and action tasks created on a local IDE and synchronizing it back into Actions Pro

Requirements​

You need to install GIT on all of your Actions Pro instances. A central git repository folder has to be created on the local environment.  If used to share content between local environment created through external IDE and Actions Pro, Git has to be installed on the local machine as well. 

Description of Components​

The Git Synchronization package presented here allows developers of Actions Pro automations (runbooks and action tasks) to work simultaneously on the same automation content and synchronize their latest changes among the Actions Pro instances they work on.
The Git Synchronization tooling consists of the following components:

  1. System.GitPushAutomationChanges This is an Actions Pro runbook which transfers the contents of a changed runbook or an action task to a predefined file system location which is a git repository.
  2. System.GitPollAutomationChanges This is an Actions Pro runbook which periodically (each 15 minutes, by default) checks a predefined file system location (same as above) for content changes and if such are found, it calls another runbook (the System.GitPullAutomationChanges runbook) to pick up and update those changes in the local Actions Pro instance database.
  3. System.GitPullAutomationChanges This is an Actions Pro runbook which checks the predefined file system location for changes and if such are found, updates them from the file system to the local Actions Pro instance's database.

Each of these runbooks consists of several action tasks which are discussed in detail later in the document.
Besides the three runbooks which perform the actual synchronization, there are four additional components in the package:

  1. GIT_POLL – This is an Actions Pro job scheduler which executes the System.GitPollAutomationChanges runbook. By default, it is set to run every 15 minutes. Also, when first installed, it is inactive and must be set to "active" by the admin if they want to have an automatic scheduled synchronization.  If the job remains "inactive" the System.GitPollAutomationChanges Runbook will not be triggered and the latest changes on the git repository will not be automatically fetched and imported in Actions Pro. The GIT_POLL job can be found in "System Administration" > "Job Scheduler" page.  There are two default parameters in GIT_POLL job schedule that can be customized according to the specific use case:
    • GIT_EXECUTE_TIMEOUT - default value is 30 minutes. It is used to extend the System.GitPullAutomationChanges execution timeout in case large amount of content has to be distributed across the environments. Extending the timeout guarantees that all Runbooks and ActionTasks are successfully shared before the Runbook times out.
    • CONSIDER_GIT_PULL_RESULTS - default value is "true". When set to "true" the System.GitPullAutomationChanges Runbook takes into consideration the result of the "git pull" operation.  If there is no change it does not update anything. When set to "false", the System.GitPullAutomationChanges Runbook considers all changes from the latest successful commit in the git repository (the latest successful commit is the SHA number coming from git and is stored in the .sync file). Refer to Scheduled Execution of Runbooks with Job Scheduler for further details on using Job Schedules.
  2. GIT_PATH – This is an Actions Pro Action Task property. The user must update it with the full path to the git repository on the file system. This is the location used by the synchronization runbooks to store and read runbook/action task content. By default, it is set to "./git".
    The GIT_PATH property can be found in "Action Definition" > "Properties" page. It is available to users without admin permissions.
    note

    Make sure there is no empty space left before or after the path to the git repository in the file system, as it interferes with the System.GitPollAutomationChanges Runbook execution.

    Refer to Properties for further details on using task properties.
  3. In order for the git synchronization to be enabled the following System Properties are introduced:
    1. "sync. Content" – Enables/disables the whole git synchronization feature. By default, it is set to "false". This disables the automatic export of changed runbook or action task content to the local git repository location. The admin must set it to "true" so content can be automatically synchronized to git.
    2. "sync.content.name.push" – This system property contains the full name of the push runbook. By default, it is set to "System.GitPushAutomationChanges". This property is used to get the name of the runbook which takes the changed content from Actions Pro and writes it to the specified file system location (denoted by GIT_PATH). Actions Pro will automatically call the runbook specified by this property, when the user commits a runbook or an action task and pass the corresponding (runbook or action task) ID to the runbook. 

How to Use the GIT Synchronization Feature​

Prerequisites​

There are some preliminary setup steps that the admin must perform for the Git Synchronization feature to start working properly.

Setup the Git location​

This step is performed outside of Actions Pro. The user must execute the following steps before they start synchronizing any content:

  1. The location on the file system where the Git repository will be cloned, must be accessible by the RSControl process (i.e. have read/write access).
  2. The git repository must be setup there, i.e. "cloned" (please refer to the Git SCM official documentation on how to perform git clone).
  3. The correct git branch must be checked out. Note, that Actions Pro will not change git branches, it will work with the current branch that is checked out.
  4. The git credentials for the repository must be saved/configured, so that executing git commands on the repository does not ask for credentials every time (please refer to the Git SCM official documentation on how to config git credentials).
  5. The path to the "git" executable must be added in the PATH environment variable of the operating system.

Enable the Push synchronization feature​

The "push" mechanism (saving changes in runbooks and action tasks to the predefined git location) is enabled by setting the "sync.content" system property to "true". When this is done, Actions Pro will automatically execute the System.GitPushAutomationChanges runbook every time the user commits a runbook or an action task.

note

Runbooks and action tasks are synchronized only on commit. When the user just saves a runbook or an action task, synchronization does not happen.

note

Runbooks in the "System" namespace and action tasks in the "resolve" namespace are not synchronized.

Enable the Poll synchronization feature​

The automatic "poll" mechanism is enabled by activating the GIT_POLL job schedule. (When first installed/upgraded, the GIT_POLL schedule is not active.) By default, the schedule runs the "System.GitPollAutomationChanges" runbook every 15 minutes.

Synchronization Process Details​

File structure of the Git Location​

The synchronization expects and pertains the following file structure on the git location:

<root>
  ActionTasks [dir]
    action_task_namespace [dir]
      action_task_name [dir]
        asses [file]
        content [file]
        general [file]
        parameters [file]
        parser [file]
        preprocess [file]
  Runbooks [dir]
    runbook_namespace [dir]
      runbook_name [dir]
        automation_abort_model [file]
        automation_main_model [file]
        decision_tree [file]
        decision_tree_options [file]
        metadata [file]
        parameters [file]
        wiki_page_content [file]

Action Task Files​

*File "assess".* Contains the groovy code from the "assess" field of the task. The file is present and empty if the action task has no "assess" content.

*File "content".* Contains the groovy code from the "content" field of the task, if such is present. If not, the "content" file is empty.

*File "general".* Contains data from the "General" tab of the action task (in the UI). It is in JSON format. An example of a "general" file:

\{
  "u_name": "New",
  "u_namespace": "ExampleActionTask",
  "u_menu_path": "/ExampleActionTask",
  "u_description": "",
  "u_summary": "",
  "invocations": \[\],
  "u_args": "",
  "u_type": "ASSESS",
  "u_timeout": "300",
  "u_command": "",
  "u_active": "false"
\}

File "parameters". Contains the parameters defined in the action task. It is in JSON format. An example of a "parameters" file:

\[
    \{
        "u_name": "ACTION_LIST",
        "u_default_value": "",
        "u_description": "List of action tasks",
        "u_encrypt": false,
        "u_type": "INPUT",
        "u_group_name": "UNCLASSIFIED"
    \},
    \{
        "u_name": "CONFLICT_LIST",
        "u_default_value": "",
        "u_description": "List of map of conflicts",
        "u_encrypt": false,
        "u_type": "OUTPUT",
        "u_group_name": "null"
    \}
\]
\\

*File "parser".* Contains the groovy code from the "parser" field of the task. The file is present and empty if the action task has no "parser" content.

*File "preprocess".* Contains the groovy code from the "preprocess" field of the task. The file is present and empty if the action task has no "preprocess" content.

Runbook Files​

*File "automation_abort_model".* The Abort model XML. The content is the same as the "u_model_exception" column in the "wikidoc" DB table.

*File "automation_main_model".* The Main model XML. The content is the same as the "u_model_process" column in the "wikidoc" DB table.

*File "decision_tree".* The decision tree. The content is the same as the "u_decision_tree" column in the "wikidoc" DB table.

*File "decision_tree_options".* The decision tree options. The content is the same as the "u_dtoptions" column in the "wikidoc" DB table.

*File "metadata".* A number of fields populated from the "wikidoc" table. It is in JSON format. An example file:

\\

\{
    "UDisplayMode": "wiki",
    "UHasActiveModel": true,
    "UHasResolutionBuilder": true,
    "UIsActive": true,
    "UIsDefaultRole": false,
    "UIsDeleted": false,
    "UIsHidden": false,
    "UIsLocked": false,
    "UIsRequestSubmission": false,
    "UIsRoot": false,
    "UIsTemplate": false,
    "ULastReviewedBy": "",
    "ULockedBy": "",
    "USIRRefCount": 0,
    "UVersion": 4,
    "sysCreatedBy": "admin",
    "sysCreatedOn": \{
        "date": 22,
        "hours": 10,
        "seconds": 43,
        "month": 9,
        "nanos": 0,
        "timezoneOffset": -180,
        "year": 119,
        "minutes": 25,
        "time": 1571729143000,
        "day": 2
    \},
    "sysUpdatedBy": "admin",
    "sysUpdatedOn": \{
        "date": 22,
        "hours": 10,
        "seconds": 57,
        "month": 9,
        "nanos": 0,
        "timezoneOffset": -180,
        "year": 119,
        "minutes": 26,
        "time": 1571729217000,
        "day": 2
    \},
    "UAdminRoles": "admin,resolve_dev,resolve_process,resolve_user,security_admin,security_designer",
    "UDTAbortTime": 0,
    "UExecuteRoles": "admin,resolve_dev,resolve_process,resolve_user,security_admin,security_designer",
    "UFullname": "ExampleRunbook.NewAutomation",
    "UIsStable": true,
    "UName": "NewAutomation",
    "UReadRoles": "admin,resolve_dev,resolve_process,resolve_user,security_admin,security_designer",
    "USummary": "ExampleRunbook.NewAutomation",
    "UTitle": "ExampleRunbook.NewAutomation",
    "UWriteRoles": "admin,resolve_dev,resolve_process,resolve_user,security_admin,security_designer"
\}
\\

File "parameters". The parameters of the runbook. It is in JSON format. Similar to the parameters file in action tasks. An example file:

\[
    \{
        "name": "ITEM_LIST",
        "displayName": "ITEM_LIST",
        "type": "String",
        "fieldTip": "",
        "sourceName": "item1,item2",
        "source": "CONSTANT",
        "hidden": false,
        "column": 1,
        "order": 0,
        "id": ""
    \},
    \{
        "name": "TEST_PARAM_2",
        "displayName": "TEST_PARAM_2",
        "type": "String",
        "fieldTip": "",
        "sourceName": "test",
        "source": "CONSTANT",
        "hidden": false,
        "column": 1,
        "order": 1,
        "id": ""
    \}
\]
*File "wiki_page_contents".* The wiki page of the runbook. The content is the same as the "u_content" column in the "wikidoc" DB table.
\\

The "Push" Runbook​

Refer to Runbook Params section in Runbook Automation Designer for further details on using runbook parameters.

These are the parameters included in the "System.GitPushAutomationChanges" Runbook:

  • ACTION_TASK_LIST. A comma-separated list of action tasks by their full name (action_task_name#namespace). This parameter is used to enable manual export of a specific action task (or a number of tasks). Executing the System.GitPushAutomationChanges manually, with provided single ActionTask or comma-separated full names, takes into consideration this list of tasks only. 
  • GIT_BASEDIR. It is automatically populated from the GIT_PATH action task property.
  • SYNC_ALL_AUTOMATIONS. Set to "false" by default. It allows the users to export all available runbooks and action tasks to the git location in one run. In order to do this, the System.GitPushAutomationChanges runbook is executed manually and this property is set to "true".
    note

    Runbooks in the "System" namespace and action tasks in the "resolve" namespace are not exported.

  • WIKIDOC_LIST. A comma-separated list of runbooks by their full name (namespace.runbook_name). This parameter is used to enable manual export of a specific runbook (or a number of runbooks). Executing the System.GitPushAutomationChanges manually, with provided single Runbook or comma-separated full names, takes into consideration this list of runbooks only.

Below you can find a brief explanation of the action tasks involved:

  • Start node used to mark the starting point of the Runbook. Only one Start node can be applied. Its parameters define process level attributes to the Runbook execution, such as PROCESS_TIMEOUT. The  PROCESS_TIMEOUT setting is used to determine how long the automation will wait before timing out. Its value is set to 30 minutes explicitly for System.GitPushAutomationChanges runbook.
  • git check push prerequisites#resolve This action task does some preliminary checks if everything is set up correctly for the execution of the runbook. The following checks are performed:- whether the GIT_BASEDIR property is supplied;- whether the GIT_BASEDIR points to a valid existing directory on the file system;- whether the GIT_BASEDIR is a valid git location;- whether a valid runbook ID (GIT_WIKI_ID) parameter or action task ID (GIT_ACTION_ID) is supplied (those are automatically populated by Actions Pro, i.e. on commit of a runbook, the GIT_WIKI_ID is populated, and on commit of an action task, the GIT_ACTION_ID is populated);- if a valid ID is not populated, it checks whether a temp sync file exists (".sync-push") which contains either a runbook ID or an action task ID (more explanation on the .sync-push file follows);- if the SYNC_ALL_AUTOMATIONS parameter is set to "true", then a runbook and action task ID is not expected; this means the user has run the runbook manually and wants all content synchronized; the above checks for ID are not performed then.
  • git sync lock#resolve Implements a file-based locking mechanism on the git repository, to prevent multiple processes executing git commands on the same repository. If another git synchronization runbook is currently running, this one will stay here until the other one finishes. The LOCK_TIMEOUT_SECONDS parameter is used to set the seconds to wait before dropping the lock (this is to prevent the situation when any of the git synchronization runbook fails with an uncaught exception for some reason and leaves the locking file to stay indefinitely). By default, the LOCK_TIMEOUT_SECONDS is set to 600 seconds (10 minutes). Also, have in mind that the action task also has a timeout, so it must always be set to a value bigger than the one set in LOCK_TIMEOUT_SECONDS; otherwise, the server may drop the task itself and fail the runbook execution.
  • git pull#resolve Executes a "git pull" operation inside the git location.
  • git update incoming list#resolve This task prepares the list with action tasks and runbooks to be exported to the git repository, based on the ACTION_TASK_LIST and WIKIDOC_LIST runbook properties.
  • git update gitignore#resolve Updates the ".gitignore" file with a .sync-* entry so the sync file does not get synchronized to git (see next task).
  • git create push sync#resolve Creates a temp sync file (".sync-push") containing the supplied runbook or action task ID, if such file is not already present. If present, it appends the new ID to it.
  • git save action task#resolve Traverses the sync file (".sync-push") and gathers all IDs that are saved there. Then it filters out the IDs of the action tasks and saves their content to the git location. Default timeout of the task is 15 minutes (900 seconds).
  • git save wikidoc#resolve Traverses the sync file (".sync-push") and gathers all IDs that are saved there. Then it filters out the IDs of the runbooks and saves their content to the git location.
    Default timeout of the task is 15 minutes (900 seconds).
  • git push#resolve Executes git add \*, git commit -m "SYNC\_COMMENT, git push operations in the git location. The SYNC_COMMENT is the same one that the user supplies on committing the runbook or action task. If such comment is not supplied, a default comment "Committed Version" is set as a commit message.
  • git remove sync file#resolve If execution comes here, this means that synchronization of changed content is successfully done in git. This action task deletes the temporary sync file (".sync-push").
  • git sync unlock#resolve Removes the lock file created by "git sync lock".
  •  Еnd node terminates the automation process. Multiple End nodes are allowed but when such node is reached, the entire Runbook process completes. This means that the resources and state information are all cleaned up.

The "Pull" Runbook​

These are the parameters included in the "System.GitPullAutomationChanges" Runbook:

  • CONSIDER_GIT_PULL_RESULTS Default value is "true". When set to "true" the runbook takes into consideration the result of the "git pull" operation.  If there is no change it does not update anything. When set to "false" the runbook considers all changes from the latest successful commit in the git repository (the latest successful commit is the SHA number coming from git and is stored in the .sync file).  
  • GIT_BASEDIR. It is automatically populated from the "GIT_PATH" action task property.
  • GIT_EXECUTE_TIMEOUT. Default value is 30 minutes. It is used to extend the System.GitPullAutomationChanges execution timeout in case large amount of content has to be distributed across the environments. Extending the timeout guarantees that all Runbooks and ActionTasks are successfully shared before the Runbook times out.
  • SYNC_ALL_AUTOMATIONS. Default value is false. This parameter may be used in case the administrator (or any other Actions Pro user who has the right to execute the runbook) wants to manually trigger a synchronization of all automations that are currently available in the git repository. An example use may be when the user has deleted a runbook or an action task on the local Actions Pro instance and wishes to put it back. Since delete operations are not implemented on the git repo, the deleted runbook or action task will still be there. In that case, the user may manually start the Pull runbook and set this parameter to "true".

You can find a brief explanation of the involved action tasks below:

  • Start node used to mark the starting point of the Runbook. Only one Start node can be applied. Its parameters define process level attributes to the Runbook execution.
  • "git check dir exists#resolve" Checks whether the GIT_PATH specified by the property is an existing directory on the file system and that it is a git location.
  • "git sync lock#resolve" Explained in the description of the System.GitPushAutomationChanges model.
  • "git pull#resolve" Executes a "git pull" operation inside the git location.
  • "git update gitignore#resolve" Updates the ".gitignore" file with a ".sync-*" entry so the sync file does not get synchronized to git (see next task).
  • "git check dir for changes#resolve" Checks for an existing ".sync-<host_IP>" file which stores the SHA-1 of the last git commit that was successfully updated by the runbook. This is explained in detail later.
    note

    This file is not added in .gitignore which means that it may be committed in git.

  • Logical element – "git repo changed" If there are new commits after the last one that was processed, execution continues to "git update action tasks from git#resolve". Otherwise, the runbook completes.
  • "git update action tasks from git#resolve" Takes all changed action tasks after the last successfully processed commit and updates them in Actions Pro. If the tasks are new, they are created, otherwise the ones existing on the Actions Pro instance are updated.  Default timeout of the task is 15 minutes (900 seconds).
  • "git update wiki docs from git#resolve" The same as above, but for runbooks. Default timeout of the task is 15 minutes (900 seconds).
  • "git update sync revision#resolve" Updates the ".sync-<host_IP>" file in the root of the GIT_PATH with the current (latest) commit hash SHA-1.
  • "git sync unlock#resolve" Explained in the description of the System.GitPushAutomationChanges model.
  •  Еnd node terminates the automation process. Multiple End nodes are allowed but when such node is reached, the entire Runbook process completes. This means that the resources and state information are all cleaned up.

Updating Only Changed Content​

The changed content is defined by the last commit hash (SHA-1) that is stored in the ".sync-<host_IP>" file. It contains only this info (an example of a git commit hash: "142b98c39023260bb6f1e5f47757bf13d58a59b5").
On first execution of the runbook, such file does not exist. In this case all content on the git location is considered new (changed) and the runbook will try to import it.
Between two runs of the runbook, there may be multiple commits in the git location. So, when getting changed content, the runbook will also scan the commit messages with which a specific runbook or action task was committed in git. The exact commit message is then used when updating the specific runbook or action task.

The "Poll" Runbook​

The "System.GitPollAutomationChanges" runbook is a subset of the action tasks from the "Pull" runbook.

These are the parameters included in the "System.GitPullAutomationChanges" Runbook:

  • CONSIDER_GIT_PULL_RESULTS. Default value is "true". When set to "true" the runbook takes into consideration the result of the "git pull" operation.  If there is no change it does not update anything. When set to "false" the runbook considers all changes from the latest successful commit in the git repository (the latest successful commit is the SHA number coming from git and is stored in the .sync file).  
  • GIT_BASEDIR. It is automatically populated from the "GIT_PATH" action task property.
  • GIT_EXECUTE_TIMEOUT. Default value is 30 minutes. It is used to extend the System.GitPollAutomationChanges execution timeout in case large amount of content has to be distributed across the environments. Extending the timeout guarantees that all Runbooks and ActionTasks are successfully shared before the Runbook times out.

The model is the same as the "Pull" runbook to the point where it tests whether there are changes in the git repo. If there are, it calls the "System.GitPullAutomationChanges" runbook.

Additional Notes​

The "Push" runbook currently supports only changed runbooks and action tasks.
The following operations are not supported by this version of the runbook:

  • deletion of runbooks or action tasks;
  • move/rename of runbooks or action tasks;
  • copy of runbooks or action tasks;
    The "Pull" runbook does not support deletion of runbooks. For example, if a runbook or an action task is deleted in the git repository, the "Pull" runbook detects this change but does not take any action.

Distributing content from an independent local development environment to Actions Pro​

Prerequisites​

  1. Setup the Git location.
    This step is performed outside of Actions Pro. The user must execute the following steps before they start synchronizing any content:
    1. The location on the file system where the Git repository will be cloned, must be accessible by the RSControl process (i.e. have read/write access).
    2. The git repository must be setup there, i.e. "cloned" (please refer to the Git SCM official documentation on how to perform git clone).
    3. The correct git branch must be checked out. Note, that Actions Pro will not change git branches, it will work with the current branch that is checked out.
    4. The git credentials for the repository must be saved/configured, so that executing git commands on the repository does not ask for credentials every time (please refer to the Git SCM official documentation on how to config git credentials).
    5. The path to the "git" executable must be added in the GIT_PATH variable on the Actions Pro environment.
    6. The GIT_POLL job schedule must be set "active" on the Actions Pro environment.

Synchronizing local changes with Actions Pro​

  1. Apply necessary changes and updates to the Runbook or Action Task files and save .
  2. Execute git add *
  3. Execute git commit -m "custom comment"
    note

    Providing a custom message is mandatory in git commit.

  4. Execute git push

Import / Export​

The git synchronization package is automatically installed. It is listed as "gitsync" in the Package Manager section in Actions Pro.

The "gitsync" package contains the 3 git synchronization runbooks: System.GitPushAutomationChagnes, System.GitPullAutomationChanges, System.GitPollAutomationChanges, together with their action tasks, plus a "GIT_PATH" action task property and a "GIT_POLL" scheduler.

Troubleshooting​

Q: What Happens On System.GitPushAutomationChanges Failure?
A: The "git check push prerequisites" action task fails. This means the correct path to the git location is misconfigured (either a wrong/non-existing directory, or not a git repository), or the runbook execution is started manually without setting the "SYNC_ALL_AUTOMATION" parameter to "true" and the previous run of the runbook was successful (this means no .sync-push file exists on the file system).

Q: In which cases Sync.GitPushAutomationChanges Runbook has to be run manually?
A:   1.When all content has to be pushed and shared across the other environments by setting the "SYNC_ALL_AUTOMATIONS" property to "true", which exports all available runbooks and action tasks.

  1. When specific list of runbooks and/or action tasks have to be shared across the other environments by setting values to the ACTION_TASK_LIST and/or WIKIDOC_LIST runbook parameters. For details refer to System.GitPushAutomationChanges Runbook parameters section.
  2.  After an unsuccessful previous run of the Sync.GitPushAutomationChanges Runbook. In this case, a ".sync-push" file will exist on the file system with the IDs of runbooks and/or action tasks which were not successfully exported to git last time.
  3. When any of the other action tasks fails. In this case a temporary ".sync-push" file needs to exist on the file location. It will contain all IDs of runbooks and action tasks which were not successfully synchronized to git. For example, if the runbook was automatically executed by Actions Pro on two commits of action tasks and the two executions were unsuccessful, the .sync-push runbook will contain the two action task IDs.

Q: Why does the git push Action Task in System.GitPushAutomationChanges Runbook fail with  command "git add" exited with an error

Detail:
fatal: pathspec  'Actiontasks/*' did not match any files

A:  This error is an indication that the paths to the local repository do not exist. When setting up the git repo for the first time (this is done manually, for further details refer to "How to Use the GIT Synchronization Feature" section in this document), the two default synchronization directories need to be created manually. Then a dummy file inside each directory has to be created with some text content (git does not commit to empty directories). The directory structure should look like this:

 <git root>
   |    
   | - ActionTasks (this is a folder)
   |        |
   |        | - readme.txt (this is a dummy file with some content, could be just one symbol)
   |
   | - Runbooks (this is a folder)
             |
             | - readme.txt (this is a dummy file with some content, could be just one symbol)

The <git root> on the file system (by default it will be in the <Actions Pro home>/git subfolder, e.g. "/opt/resolve/git"; can be changed via the GIT_PATH action task property.

Q: What is the format of the ".sync-push" file? A: The ".sync-push" file contains IDs of runbooks and/or action tasks. Each ID is written in a new line and preceded by "at:" for an action task ID or "rb:" for a runbook ID. 
Example ".sync-push" file:

at:ff8080816d5f6bc9016d607a55280008
at:2905b038c0a8a217003d55da3bf24403
rb:2c9181e62f5029db012f514b9b140006

The ID corresponds to the "sys_id" column in the corresponding DB table ("wikidoc" or "resolve_action_task")

Q: What Happens On System.GitPullAutomationChanges Failure?
A: At any time during the runbook execution, a failure can occur. In this case the runbook may have updated only a part of all runbooks and action tasks that were changed on the git location.

Since the ".sync-<host_IP>" file is updated as a last step, the above scenario will leave this file unchanged (execution will fail before it gets to this step). Thus, on the next run, the runbook will try to update the same runbooks and action tasks (some of them may have already been updated before the runbook failed the last time).

Q: In which cases Sync.GitPullAutomationChanges Runbook has to be run manually?
A: For example: there is one action task and one runbook that need to be updated. Since action tasks are updated first, the action task gets updated. The task for updating the runbook fails for some reason. On the next run of the pull runbook, it will try to update the same action task and runbook. Since the same action task was successfully updated on the previous run, it will not be updated in this run (no changed content, no new version in Actions Pro). Only the Runbook will be updated on the second "pull" execution.

Q: Why there are no worksheets of the System Git Runbooks in the WS Results?
A: 1. The System.GitPushAutomationChanges, System.GitPollAutomationChanges, System.GitPullAutomationChanges runbook is deactivated. Only users with admin permissions have access to the "Wiki Administration" page where the Runbooks can be activated again. Activating the runbok/s does not execute it automatically. After successful activation the respective runbook has to be run manually with all required runbook parameters as described above.

  1. sync.content system property is set to "false". User with admin permissions has access to "System Properties" page and can set it to "true". After that the required Git Runbooks have to be executed manually.

Q: Why runbooks that are deleted from the local git repository can still be found on the Actions Pro environment and vice-versa?
A: The System.GitPushAutomationChanges runbook currently supports only changes related to "commit" operation.  The following operations are not supported by this version of the runbook:

  • deletion of runbooks or action tasks;
  • move/rename of runbooks or action tasks;
  • copy of runbooks or action tasks;

The System.GitPullAutomationChanges runbook does not support deletion of runbooks. For example, if a runbook or an action task is deleted in the git repository, the "Pull" runbook detects this change but does not take any action.

Q: What does the number before the commit message mean?
A: When a change is pulled from the centralized git repository it carries the original short Git version hash and original user comment with it. The hash version can be used by the developers to communicate the exact version in which changes occurred between the two independent Actions Pro environments. Example: User A works on Actions Pro node1 and creates a Runbook with 4 draft versions before committing the stable latest changes. User B works on Actions Pro node2 and has not started development on this runbook yet. 15 minutes after User A committed the latest changes node2 pulls the updates from the git repository. User A sees 5 versions while user B sees 1 version. In order to communicate the right version they use the short Git version hash. 

Q: Why some committed versions' messages display the short Git version hash followed by a custom comment while others display short Git version hash and a generic "Committed Version" comment?
A: When performing the initial synchronization pull from the centralized git repository all newly save versions receive the "Committed Version" system message. All manually committed changes require a comment message to be provided.

Q: Does Git synchronization work when any of the Git sync runbooks is deactivated? 
A: Yes. As long as the sync.content system property value is set to "true" the content distribution mechanism works. If any of the Git sync runbooks is deactivated, it can be re-activated from "Wiki Administration" page and executed. 

Q: What if GIT_POLL Job Schedule has been left "Inactive" while several commits have been pushed to the git repository?
A: Two possible solutions:

  1. set the GIT_POLL job schedule to "Active" and wait for the Sync.GitPollAutomationChanges Runbook to be executed.
  2. Manually execute the Sync.GitPollAutomationChanges Runbook.
note

Only the latest committed changes will be pulled and saved as a new "committed" version.

Q: What if Sync.GitPullAutomationChanges times out before all content is pulled and saved? 
A: 1. Based on the amount of content that has to be pulled initially, the time might not be sufficient for the Sync.GitPullAutomationChanges runbook to finish. Increasing the Sync.GitPullAutomationChanges Runbook execution time is managed through the GIT_EXECUTE_TIMEOUT parameter in Sync.GitPollAutomationChanges Runbook. Default timeout is 30 minutes.

  1. Another solution is to re-run the Sync.GitPullAutomationChanges runbook. It will examine all available content for updates and if such occurred it will pull them. The content without any changes will be skipped.

Q: Why "git push" command on the local machine fails with error: "failed to push some refs to"?
A: There are updates in the centralized git repository folder which first need to be pulled before pushing the local changes.

First execute "git pull" followed by "git push" commands.

Q: Why do I see system commit message "Merge branch '_branch_name' of /repo-path "_ in the Version List?
A: When the developer commits a change on the local environment, which is not up to date with the latest git repository where other commits over the same file have occurred, then git  attempts to merge the changes and generates such system message.

Post Validation​

If there is a problem with the feature functionality, you can check the following log file - rscontrol.log or the corresponding worksheets in Details field of the failed task.