Gort is a chatbot framework designed from the ground up for chatops.

Gort

GoDoc Tests Go Report Card

Gort is considered "minimally viable", but is still a work in progress under active heavy development. Follow for updates!

Gort is a chatbot framework designed from the ground up for chatops.

Gort brings the power of the command line to the place you collaborate with your team: your chat window. Its open-ended command bundle support allows developers to implement functionality in the language of their choice, while powerful access control means you can collaborate around even the most sensitive tasks with confidence. A focus on extensibility and adaptability means that you can respond quickly to the unexpected, without your team losing visibility.

The official documentation can be found here: The Gort Guide.

History

Gort was initially conceived of as a Go re-implementation of Operable's Cog, and while it remains heavily inspired by Cog, Gort has largely gone its own way.

During our initial design discussion, we found that many of Cog’s features, however innovative, went largely unused, and the codebase had become difficult to extend and maintain. Additionally, its implementation language -- Elixir -- had relatively few proficient developers. The solution, which was discussed for many months on the Cog Slack workspace, was to rewrite Cog from scratch in Go, removing some of less-used functionality and reducing complexity in the process.

This gave us the opportunity to consider and possibly redefine what Cog was meant to be. To choose the features that make sense, and to discard those that don't. In this way, Gort can be described more as a “spiritual successor” to Cog than a faithful re-implementation.

Features

Gort's design philosophy emphasizes flexibility and security by allowing you to build commands in any language you want, using tooling you're already comfortable with, and can tightly control who can use them and how.

More specifically:

  • Commands can be implemented in any programming language
  • Users may trigger commands through Slack (or another chat provider)
  • Commands are packaged into bundles that can be installed in Gort
  • Users can be assigned to groups, roles can be assigned to groups, and permissions can be attached to roles
  • Supports a sophisticated identity and permission system to determine who can use commands
  • All command activities are stored in a dedicated audit log for review

Each of these is described in more detail below.

Users may trigger commands through Slack (or another chat provider)

Users primarily interact with Gort through commands, which are triggered by a command character (! by default) but are otherwise conceptually identical to commands entered on the command line.

For example, using an echo command might look like the following:

Hello, Gort!

As shown, the output from successful commands is relayed back by Gort.

More information about commands can be found in the Gort Guide:

Commands can be implemented in any programming language

Gort commands are built as container images, which means you can build them in any language you're comfortable with.

What's more, because your executable receives all chat inputs exactly as if it was being typed on the command line, you can use any command line interpreter you want. Commands can even be implemented as Bash scripts, or using existing commands, like curl!

More information about writing commands can be found in the Gort Guide:

Commands are packaged into bundles that can be installed in Gort

In Gort, a set of one or more related commands can be installed as a "command bundle".

A bundle is represented in YAML, specifying which executable to use for each command and who is allowed to execute each commands.

A very simple bundle file is shown below.

---
gort_bundle_version: 1

name: echo
version: 0.0.1
author: Matt Titmus <[email protected]>
homepage: https://guide.getgort.io
description: A test bundle.
long_description: |-
  This is an example bundle. It lets you echo text using the "echo"
  command that's built into Ubuntu 20.04.

permissions:
  - can_echo

docker:
  image: ubuntu
  tag: 20.04

commands:
  foo:
    description: "Echos back anything sent to it."
    executable: [ "/bin/echo" ]
    rules:
      - must have echo:can_echo

This shows a bundle called echo, which defines a command (also called echo) and a permission called can_echo. Once installed, any user with the echo:can_echo permission can execute it in Slack.

More information about bundles can be found in the Gort Guide:

Organize users into groups, and permissions into roles

In Gort, users can be uniquely mapped to users in one or more chat providers. Gort users can be members of one or more groups, which in turn can have any number of roles that can be thought of as collections of granted permissions. For example, the user dave might be in a group called developers. This group may have a role attached named deployers that contains a number of permissions, including one called production_deploy.

More information about permissions and rules can be found in the Gort Guide:

Use a sophisticated identity and permission system to determine who can use commands

A sophisticated rule system can be applied for each command defining who can use it. These can be quite granular, and are even capable of making permissions decisions based on the values of specific flags or parameters.

Rules are assigned at the bundle level, and can be quite sophisticated. Below we have a subset of a bundle called deploy.

name: deploy
version: 0.0.1

permissions:
  - production_deploy

commands:
  deploy:
    description: "Deploys to the chosen environment."
    executable: [ "/bin/deploy" ]
    rules:
      - with arg[0] == "production" must have deploy:production_deploy

As you can see, the above example includes one command, also called deploy. Its one rule asserts that any user passing "production" as the parameter must have the production_deploy permission (from the deploy bundle).

More information about permissions and rules can be found in the Gort Guide:

Record all command activities in an audit log

All command activities are both emitted as high-cardinality log events (shown below) and recorded in an audit log that's maintained in Gort's database.

Take, for example, a user executing the !bundle list command from Slack:

bundle list

This will generate log output similar to the following:

INFO   [49594] Triggering command   adapter.name=Gort bundle.default=false bundle.name=gort bundle.version=0.0.1
                                    command.executable="[/bin/gort bundle]" command.name=bundle
                                    command.params=list gort.user.name=admin provider.channel.id=C0238AZ9QNB
                                    provider.channel.name=gort-dev [email protected]
                                    provider.user.id=U023P43L6PL trace.id=476b3089c8ce0d38a2915a3b58fde032

As you can see, this rich event includes:

  • The chat provider ("Gort", as named in the configuration), and channel within it
  • The triggered bundle (and its version) and command (and executable), and the parameters passed to it
  • The name of the user (both the Gort user ID and Slack user ID)
  • A unique trace ID that's used by all log events associated with this invocation.

Note that this example uses "human readable" format for readability. In production mode Gort generates JSON-encoded log events.

More information about audit logging can be found in the Gort Guide:

How to Run the Gort Controller

For more information, take a look at the Quick Start Guide in The Gort Guide.

The Gort Client

The gort binary also serves as the controller administration CLI.

Configuring Client Profiles

The gort client uses a YAML-formatted configuration file, conventionally located in the profile file in a .gort directory in your home directory. This is where you can store connection credentials to allow gort to interact with the Gort's Controller's REST API.

An example .gort/profile file might look like this:

defaults:
    profile: gort

gort:
    url: https://gort.mycompany.com:4000
    password: "seekrit#password"
    user: me

preprod:
    url: https://gort.preprod.mycompany.com:4000
    password: "anotherseekrit#password"
    user: me

Comments begin with a # character; if your password contains a #, surround the entire password in quotes, as illustrated above.

You can store multiple "profiles" in this file, with a different name for each (here, we have gort and preprod). Whichever one is noted as the default (in the defaults section) will be used by gort. However, you can pass the --profile=$PROFILE option to gort to use a different set of credentials.

While you can add profiles to this file manually, you can also use the gort profile create command to help.

Getting Help

The gort executable contains a number of commands and sub-commands. Help is available for all of them by passing the --help option. Start with gort --help, and go from there.

Status of This Project

Gort is in a state of active heavy development. The date that various milestones have been achieved are listed below. The number and focus of present and future milestones are subject to change.

  • Project created: 27 December 2018
  • Milestone 1: 7 January 2019
  • Milestone 2: 21 January 2019
  • Milestone 3: 24 January 2019
  • Milestone 4: 17 March 2019
  • Milestone 5: 7 June 2021
  • Milestone 6: 10 June 2021
  • Milestone 7: 15 June 2021
  • Milestone 8: 26 July 2021 (alpha: 2 July 2021; beta: 15 July 2021)
  • Milestone 9: TBD
  • Release candidate 1: TBD
  • Release!: TBD

More Links

Owner
Gort
Gort is a chatbot framework designed from the ground up for chatops.
Gort
Comments
  • Docker error running postgres tests

    Docker error running postgres tests

    Running make test I see the following error on the github.com/clockworksoul/gort/dataaccess/postgres package.

         base_test.go:53: 
             	Error Trace:	base_test.go:53
             	Error:      	Received unexpected error:
             	            	Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
             	Test:       	TestMain
             	Messages:   	failed to start database container
    

    I'm running Docker Desktop 3.3.3 on MacOS (docker engine version 20.10.6).

  • problems initializing the database?

    problems initializing the database?

    I get this error after connecting gort to postgres, gort was deployed to kubernetes using helm.

    contains: pq: column "docker_image" of relation "bundles" does not exist  error="error reported by the data store\n  contains: pq: column \"docker_image\" of relation \"bundles\" does not exist" status=500
    INFO   [0023] REST service event                            addr="10.244.164.42:45428" request="POST /v2/bootstrap HTTP/1.1" size=108 status=500 user=-
    

    potentially related, I was receiving errors when gort attempted to create the database, the "CREATE DATABASE $1" string was being interpreted literally by postgres, which then throws a syntax error. I recompiled it with "gort" hardcoded in place of "$1" to move past that.

  • DAL: postgres connections not being closed

    DAL: postgres connections not being closed

    noticed something interesting after building the code in the main branch: on every message sent in a channel that gort is in, a dangling connection is left open in postgres, eventually leading to the max_connections parameter being reached, which consequently causes gort to respond to every message in the channel with an error.

    I think there are potentially two issues here: the connections being left open is obviously one, and potentially the second being that we might not want gort automatically responding to DAL related errors in the chat service, this is quite noisy and a real nuisance to people not familiar with the bot itself.

  • WIP: allow kubernetes Secrets to be injected into the worker's environment

    WIP: allow kubernetes Secrets to be injected into the worker's environment

    As stated, this should probably be considered a WIP, it's only been implemented for postgres, and ideally it would let you 1) mount multiple secrets into the environment, and 2) mount Secrets into the worker's filesystem. this currently provides the functionality I need to use this bot in a more production'y manor right now, but I may circle back to do more work on it if time allows, and if it's not the totally wrong direction for this kind of thing that folks have envisioned for the project.

  • Support for commands output formatting with templates: initial version

    Support for commands output formatting with templates: initial version

    Support for output formatting templates.

    This will resolve https://github.com/getgort/gort/issues/116. The changes are BIG.

    TL;DR:

    • Templates can be set at the config, bundle, and command level. There are also default templates that work fine.
    • The template syntax is based on Go templates. For example, this is the default command error message template:
    {{ header | color "#FF0000" }}{{ .Response.Title }}{{ endheader }}
    {{ text }}The pipeline failed planning the invocation:{{ endtext }}
    {{ text | monospace true }}{{ .Request.Bundle.Name }}:{{ .Request.Command.Name }} {{ .Request.Parameters }}{{ endtext }}
    {{ text }}The specific error was:{{ endtext }}
    {{ text | monospace true }}{{ .Response.Out }}{{ endtext }}
    
    • Message elements are described using custom Go template functions (header, text, etc)
    • On command execution, the resulting CommandResponseEnvelope value is passed to the templating engine.
      • The adapter will detect whether command output is JSON-formatted (json.Valid does this easily)
        • If yes: the response if unmarshalled into an interface{} value (envelope.Payload) where it is accessible via Go template syntax
        • If not: the response text is placed, unmodified, into the envelope’s Payload as a string.
    • Moved some repeated and more general logic into the adapter package and out of the implementations.

    I'll write more later.

    TODO still:

    • Documentation (will come in a separate PR).

    Open Question:

    • Should a given template be expected to work for ALL chat providers, or should we support the ability to set templates at the chat level?
      • This would mean that each adapter in the config would support template definitions (easy)
      • Each command and bundle would also need support for setting each of the two command template types for each supported adapter type. Is that too much complexity?
  • Create `permission` subcommands

    Create `permission` subcommands

    As described in the documentation, we should have the following commands:

    • gort permission info
    • gort permission list

    Edit: permissions --> permission

  • send feedback when a recognized command is found

    send feedback when a recognized command is found

    This is pretty basic, and while only tested with slack, it seems like it should be adapter agnostic. it provides all of the feedback I wanted/needed in #186

  • Add acknowledgement responses when a command is being executed

    Add acknowledgement responses when a command is being executed

    something that might be cool is if gort could have a custom acknowledgement command when it is starting to execute a command in a bundle. larger container images that take time to pull on a fresh kubernetes node could leave a user questioning whether or not the command was recognized, which could lead to instances of commands being sent to gort multiple times, etc.

  • Question: how to retrieve container images from private registries?

    Question: how to retrieve container images from private registries?

    As it says on the tin, there's no official way to retrieve images from private registry.

    This is easily solvable if Gort is deployed in Kubernetes -- do we want to make that the official solution, or do we want to make it possible to provide some kind of registry credentials?

  • Add fallback text to output elements

    Add fallback text to output elements

    Fixes #150

    Tested with updates to test-bundle.yml

    Adds two new template tags: "unimplemented" which should not be handled by adapters to allow testing fallback to alt text, and "alt" which allows a template to specify its alternate text explicitly.

    If "alt" is not provided, a concatenation of all element text is output as the fallback, separated by empty lines.

  • Add Socket mode adapter as new default

    Add Socket mode adapter as new default

    Using a Classic Slack app is still supported, but results in a deprecation warning.

    Socket mode is enabled by specifying the new app_token and bot_token fields of the slack config yaml instead of the Classic api_token field.

    A manifest file is provided to configure a new Socket mode app with the appropriate scopes.

    Fixes #84

  • Postgres connection leak

    Postgres connection leak

    The postgres dataaccess implementation seems to still have a connection leak. I reached too many connections by executing the following commands:

    ./gort bootstrap --allow-insecure -F 127.0.0.1:4000
    !whoami
    ./gort group add admin theprogrammerjack
    ./gort config set -b incidents -k YEXT_PAGERDUTY_API_TOKEN value
    ./gort config set -b incidents -k YEXT_PAGERDUTY_API_TOKEN value
    ./gort config get -b incidents
    ./gort group (shouldn't hit server, just helptext)
    ./gort group list
    ./gort group list (first failure)
    !config set -b incidents -k YEXT_PAGERDUTY_API_TOKEN value (also failure)
    

    Those preceded by ! were executed through slack, while the rest were executed in the terminal locally. It's worth noting that all of the commands that hit the server were unauthorized due to #232.

  • Fix dynamic config list in memory

    Fix dynamic config list in memory

    The in-memory implementation of dynamic config had a slightly incorrect regex for its wildcard, resulting in DynamicConfigurationList always returning an empty slice. This is now corrected.

  • The Gort cli can completely stop authenticating properly

    The Gort cli can completely stop authenticating properly

    I don't have exact instructions to reproduce, but this has now happened to me multiple times while using the postgres dataaccess and not at all while using in memory. After successfully executing several commands, the gort cli stops authenticating properly, a problem which persists across gort restarts. The complete state of the database after this has happened can be found here. In this example, I managed to give my slack user admin permissions before the cli lost its own.

    This should probably been investigated further at some point, but may just be on my end, since I don't believe anyone else has experienced it so far.

  • Limit how many times a scheduled command runs

    Limit how many times a scheduled command runs

    At the moment, any scheduled command will repeat indefinitely according its cron-format schedule. By adding an optional limit on how many times it can run before being deleted, we can enable one-off scheduled commands as well as commands that just run for a limited amount of time.

  • Slack link bookmarks

    Slack link bookmarks

    This PR adds an advanced output action, bookmark, which creates a link bookmark in slack and is a no-op in discord. The action requires a Title, link in Content, and an optional Adapter. If no adapter is specified, the one from which the command was issued will be used.

FactoriGOChatBot - A Discord chatbot for Factorio written in Golang

FactoriGOChatBot A Discord chatbot for Factorio written in Golang This bot will

Oct 16, 2022
Simple yet customizable bot framework written in Go.
Simple yet customizable bot framework written in Go.

Introduction Sarah is a general-purpose bot framework named after the author's firstborn daughter. This comes with a unique feature called "stateful c

Dec 12, 2022
Golang Framework for writing Slack bots

hanu - Go for Slack Bots! The Go framework hanu is your best friend to create Slack bots! hanu uses allot for easy command and request parsing (e.g. w

Oct 24, 2022
Telegram Bot Framework for Go

Margelet Telegram Bot Framework for Go is based on telegram-bot-api It uses Redis to store it's states, configs and so on. Any low-level interactions

Dec 22, 2022
Slack Bot Framework

slacker Built on top of the Slack API github.com/slack-go/slack with the idea to simplify the Real-Time Messaging feature to easily create Slack Bots,

Dec 25, 2022
Slack bot core/framework written in Go with support for reactions to message updates/deletes
Slack bot core/framework written in Go with support for reactions to message updates/deletes

Overview Requirements Features Demo The Name Concepts Create Your Own Slackscot Assembling the Parts and Bringing Your slackscot to Life Configuration

Oct 28, 2022
Telebot is a Telegram bot framework in Go.

Telebot "I never knew creating Telegram bots could be so sexy!" go get -u gopkg.in/tucnak/telebot.v2 Overview Getting Started Poller Commands Files Se

Dec 30, 2022
Parr(B)ot is a Telegram bot framework based on top of Echotron

Parr(B)ot framework A just born Telegram bot framework in Go based on top of the echotron library. You can call it Parrot, Parr-Bot, Parrot Bot, is up

Aug 22, 2022
Automated Trader (at). Framework for building trading bots.
Automated Trader (at). Framework for building trading bots.

Automated Trader (at) Purpose: Framework for building automated trading strategies in three steps: Build your own strategy. Verify it with the backtes

Dec 14, 2022
Ground control - Ground station software for my rover project (Mk II)

Prototype rover ground station code About This is part of a second iteration of a rover vehicle (the first being https://github.com/DanCrank/tank-bot-

Jan 3, 2022
Glow is a terminal based markdown reader designed from the ground up to bring out the beauty—and power—of the CLI.💅🏻
Glow is a terminal based markdown reader designed from the ground up to bring out the beauty—and power—of the CLI.💅🏻

Glow Render markdown on the CLI, with pizzazz! What is it? Glow is a terminal based markdown reader designed from the ground up to bring out the beaut

Dec 30, 2022
Chatto is a minimal chatbot framework in Go.
Chatto is a minimal chatbot framework in Go.

chatto Simple chatbot framework written in Go, with configurations in YAML. The aim of this project is to create very simple text-based chatbots using

Dec 3, 2022
Go Wechaty is a Conversational SDK for Chatbot Makers Written in Go
Go Wechaty is a Conversational SDK for Chatbot Makers Written in Go

go-wechaty Connecting Chatbots Wechaty is a RPA SDK for Wechat Individual Account that can help you create a chatbot in 6 lines of Go. Voice of the De

Dec 30, 2022
A small chatbot for ssh-chat

ssh-chat-bot A small chatbot for ssh-chat. Installation go get -u github.com/sechanakira/ssh-chat-bot You can also clone the repo and then run make in

Nov 25, 2021
FactoriGOChatBot - A Discord chatbot for Factorio written in Golang

FactoriGOChatBot A Discord chatbot for Factorio written in Golang This bot will

Oct 16, 2022
DeSo is a blockchain built from the ground up to support a fully-featured social network

DeSo is a blockchain built from the ground up to support a fully-featured social network. Its architecture is similar to Bitcoin, only it supports complex social network data like profiles, posts, follows, creator coin transactions, and more.

Dec 22, 2022
Testing ground for build-your-own golang/grpc demo app.

Getting started Prereqs You will need to install both Go and the protoc compiler (version 3): Go installation protoc installation Install the protobuf

Dec 15, 2021
Testing ground for CRUD backend using Golang, gRPC, protobufs

blog-example-service Simple example CRUD backend using Golang, gRPC, and protobufs. Using with MongoDB as the database (default) You will need a Mongo

Dec 16, 2021
DeSo: a blockchain built from the ground up to support a fully-featured social network

About DeSo DeSo is a blockchain built from the ground up to support a fully-feat

Dec 18, 2021