logo

CALLGOOSE

Action Git Entry Files

The Git Entry File is a YAML file that contains all the essential configuration details. It serves as the core setup for the process and needs to be placed in the designated path within the Git repository. Specifically, the file should be stored in the folder where all related files are located. Ensuring the Git Entry File is correctly placed and properly formatted is crucial for the proper execution of the associated processes.


Ensure that all the Action files are placed inside a folder, and the Git Entry File is also placed in the same folder.


Ansible Action Git Entry File

The following is the syntax of the Git Entry file for an Ansible Action.

action:
    ansible:
        # Which operation to do. Possible values are "playbook", "command"
        # "playbook" - Run the playbook. Additional commands can also be executed afterward if needed.
        # "command" - Run ansible commands.
        operation: "playbook"
        
        # Ansible playbook file (e.g., check_filesystem_usage.yml). 
        # Mandatory if the operation is "playbook", else it is optional.
        # Enter the file name only.
        playbookFile: ""
        
        # Specify options for the Ansible playbook. eg: "-e var_name=value" to pass extra variables, or "--limit=host_group" to target specific hosts
        # It is optional. You can leave it as empty.
        playbookOption: ""
        
        # Ansible commands to be executed as a part of operation.
        # If the operation is "playbook", then these commands will be executed only after completing the playbook.
        # Mandatory if the operation is "command", else it is optional.
        ansibleCommands: []
        
        # Response (exit status) indicating the action was executed successfully. For example, in Linux, an exit status of 0 indicates success.
        successExitCode: 0
        
        # Expected run time.
        # We will wait up to the specified time. If the action is not completed by then, we will consider it a failure.
        # Enter a value between 1 and 60.
        expectedRunTimeInMinutes: 10



Bash Action Git Entry File

The following is the syntax of the Git Entry file for a Bash Action.

action:
    bash:
        # Bash file (e.g., check_filesystem_usage.bsh). 
        # Enter the file name only.
        file: ""
        
        # Response (exit status) indicating the action was executed successfully. For example, in Linux, an exit status of 0 indicates success.
        successExitCode: 0
        
        # Expected run time.
        # We will wait up to the specified time. If the action is not completed by then, we will consider it a failure.
        # Enter a value between 1 and 60.
        expectedRunTimeInMinutes: 10



Kubernetes Action Git Entry File

The following is the syntax of the Git Entry file for a Kubernetes Action.

action:
    kubernetes:
        # Which operation to do. Possible values are "apply", "command"
        # "apply" - Run the Kubernetes file. Additional commands can also be executed afterward if needed.
        # "command" - Run kubernetes commands.
        operation: "apply"
        
        # Kubernetes file (e.g., nginx-deployment.yaml). 
        # Mandatory if the operation is "apply", else it is optional.
        # Enter the file name only.
        kubernetesFile: ""
        
        # Kubernetes commands to be executed as a part of operation.
        # If the operation is "apply", then these commands will be executed only after completing the operation.
        # Mandatory if the operation is "command", else it is optional.
        kubernetesCommands: []
        
        # Response (exit status) indicating the action was executed successfully. For example, in Linux, an exit status of 0 indicates success.
        successExitCode: 0
        
        # Expected run time.
        # We will wait up to the specified time. If the action is not completed by then, we will consider it a failure.
        # Enter a value between 1 and 60.
        expectedRunTimeInMinutes: 10



PowerShell Action Git Entry File

The following is the syntax of the Git Entry file for a Poweshell Action.

action:
    powershell:
        # Powershell file (e.g., check_filesystem_usage.ps1). 
        # Enter the file name only.
        file: ""
        
        # Response (exit status) indicating the action was executed successfully. For example, in Linux, an exit status of 0 indicates success.
        successExitCode: 0
        
        # Expected run time.
        # We will wait up to the specified time. If the action is not completed by then, we will consider it a failure.
        # Enter a value between 1 and 60.
        expectedRunTimeInMinutes: 10



Python Action Git Entry File

The following is the syntax of the Git Entry file for a Python Action.

action:
    python:
        # Python file (e.g., check_filesystem_usage.py). 
        # Enter the file name only.
        file: ""
        
        # Response (exit status) indicating the action was executed successfully. For example, in Linux, an exit status of 0 indicates success.
        successExitCode: 0
        
        # Expected run time.
        # We will wait up to the specified time. If the action is not completed by then, we will consider it a failure.
        # Enter a value between 1 and 60.
        expectedRunTimeInMinutes: 10



SSH Action Git Entry File

The following is the syntax of the Git Entry file for an SSH Action.

action:
    ssh:
        # The OS command that needs to be executed on the connected server. eg: "df -hT"
        osCommand: ""
        
        # Response (exit status) indicating the action was executed successfully. For example, in Linux, an exit status of 0 indicates success.
        successExitCode: 0
        
        # Expected run time.
        # We will wait up to the specified time. If the action is not completed by then, we will consider it a failure.
        # Enter a value between 1 and 60.
        expectedRunTimeInMinutes: 10



Terraform Action Git Entry File

The following is the syntax of the Git Entry file for a Terraform Action.

action:
    terraform:
        # Which operation to do. Possible values are "apply", "destroy", "command"
        # "apply" - Run the Terraform file with the apply command. Additional commands can also be executed afterward if needed.
        # "destroy" - Run the Terraform file with the destroy command. Additional commands can also be executed afterward if needed.
        # "command" - Run terraform commands.
        operation: "apply"
        
        # Terraform file (e.g., main.tf). 
        # Mandatory if the operation is "apply" or "destroy", else it is optional.
        # Enter the file name only.
        terraformFile: ""
        
        # Specify options for 'terraform apply/destroy'. eg: '-var-file="variables.tfvars"' to specify a file containing variable values
        # It is optional. You can leave it as empty.
        # Only valid if the operation is "apply" or "destroy"
        operationOptions: ""
        
        # Specify options for 'terraform init', which initializes the working directory. eg: '-backend-config=backend_configs.tfvars' to customize backend configurations.
        # It is optional. You can leave it as empty.
        initOptions: ""
        
        # Terraform commands to be executed as a part of operation.
        # If the operation is "apply" or "destroy", then these commands will be executed only after completing the operation.
        # Mandatory if the operation is "command", else it is optional.
        terraformCommands: []
        
        # Response (exit status) indicating the action was executed successfully. For example, in Linux, an exit status of 0 indicates success.
        successExitCode: 0
        
        # Expected run time.
        # We will wait up to the specified time. If the action is not completed by then, we will consider it a failure.
        # Enter a value between 1 and 60.
        expectedRunTimeInMinutes: 10


CALLGOOSE
SQIBS

Advanced Automation-first platform with effective On-Call scheduling, real-time Incident Management, Incident Response, and SLA tracking capabilities that keep your organization more resilient, reliable, and always on.

Callgoose SQIBS can integrate with any applications or tools you use, including monitoring, ticketing, ITSM, log management, error tracking, ChatOps, collaboration tools, or any custom applications.

In addition to alerting and response, Callgoose SQIBS enables Automated Incident Remediation, SLA tracking (MTTA, MTTR, uptime), and Incident Response Threshold monitoring, allowing teams to proactively detect risks, prevent SLA breaches, and execute remediation workflows in real time.

A built-in self-service portal empowers end users to handle routine requests independently, significantly reducing operational load on engineering and IT teams.

Callgoose provides enterprise-grade automation, SLA governance, and incident response capabilities at one of the most cost-effective price points in the market.



Unique Features

  • 30+ languages supported
  • IVR for Phone call notifications
  • Dedicated caller id
  • Advanced API & Email filter
  • Tag based maintenance mode
  • Self-service portal for operational requests
  • SLA Tracker (MTTA, MTTR, uptime monitoring)
  • Incident Response Threshold (incident timers, escalation control)
Book a Demo

Signup for a freemium plan today &
Experience the results.

No credit card required