The git2consul-go tool is used to populate a Consul key/value store from a git repo.

The baseline source code was forked from go-git2consul which was inspired by the orginal git2consul tool.

• uses the official Consul Go Lang client library
• uses native Go Lang git implementation go-git
• removal of nodejs and git runtime dependencies
• configuration is sourced locally instead of it being fetched from the Consul K/V
• transaction atomicity implies the set of keys is stored either entirely or not at all. Along with atomicity the number of the KV API calls is limited. However there is a pending issue as Consul transaction endpoint can handle only 64 items in the payload. The transactions are executed in 64 elements chunks.

git2consul-go comes in two variants:

• as a single binary file which after downloading can be placed in any working directory - either on the workstation (from which git2consul will be executed) or on the Consul node (depends whether access to the git repository is available from the Consul nodes or not)
• as a source code that can be build on the user workstation (How to build from src?)

Simple example usage.

$ git2consul -config config.json -basic -user mygituser -password mygitpass -once

Simple example config file.

{
  "repos": [
    {
      "name": "example",
      "url": "http://github.com/DummyOrg/ExampleRepo.git"
    }
  ]
}

$ git2consul -help
Usage of git2consul:
  -config string
        path to config file
  -debug
        enable debugging mode
  -once
        run git2consul once and exit
  -version
        show version

Configuration is provided with a JSON file and passed in via the -config flag. Repository configuration will take care of cloning the repository into local_store, but it will not be responsible for creating the actual local_store directory. Similarly, it is expected that there is no collision of directory or file that contains the same name as the repository name under local_store, or git2consul will exit with an error. If there is a git repository under a specified repo name, and the origin URL is different from the one provided in the configuration, it will be overwritten.

git2consul will attempt to use sane defaults for configuration. However, since git2consul needs to know which repository to pull from, minimal configuration is necessary.

Webhooks will be served from a single port, and different repositories will be given different endpoints according to their name

Available endpoints:

• <webhook:address>:<webhook:port>/{repository}/github
• <webhook:address>:<webhook:port>/{repository}/stash
• <webhook:address>:<webhook:port>/{repository}/bitbucket
• <webhook:address>:<webhook:port>/{repository}/gitlab

The "source_root" instructs the app to navigate to the specified directory in the git repo making the value of source_root is trimed from the KV Store key. By default the entire repo is evaluated.

When you configure the source_root with /top_level/lower_level the file /top_level/lower_level/foo/web.json will be mapped to the KV store as /foo/web.json

The "mount_point" option sets the prefix for the path in the Consul KV Store under which the keys should be added.

The "expand_keys" instructs the app to evaluate known types of files. The content of the file is evaluated to key-value pair and pushed to the Consul KV store.

• Text file - the file content is pushed to the KV store as it is.
• Yaml file - the file is evaluated into key-value pair. i.e configuration.yml

---
services:
  apache:
    port: 80
  ssh:
    port: 22

will be evaluated to the following keys:

• /configuration/services/apache/port
• /configuration/services/ssh/port

The "skip_branch_name" instructs the app to prune the branch name. If set to true the branch name is pruned from the KV store key.

The "skip_repo_name" instructs the app to prune the repository name. If set to true the repository name is pruned from the KV store key.

The "credentials" option provides the possibility to pass the credentials to authenticate to private git repositories.

Sample config with basic auth (login:password/token)

{
  "repos": [
    {
      "name": "example",
      "url": "http://github.com/DummyOrg/ExampleRepo.git",
      "credentials: {
            "username": "foo",
            "password": "bar"
      }
    }
  ]
}

Sample config with ssh auth

{
  "repos": [
    {
      "name": "example",
      "url": "ssh://github.com/DummyOrg/ExampleRepo.git",
      "credentials: {
            "private_key": {
                  "pk_key": "/path/to/priv_key",
                  "pk_username": "foo",
                  "pk_password": "bar"
            }
      }
    }
  ]
}

See CONTRIBUTING.md for details.

• Go 1.13+

$ make build

The end to end test can be run by simply running make test-e2e. To run the test, you need to have the consul binary available in your path. It simulates a create and update of consul KV pairs and confirms every operation is successful. The test data is stored within this repo so developers do not have to setup an external repo to test.

The tests can manually be run by starting Consul in dev mode, and then manually running git2consul with one of the config files provided. For example:

$ consul agent -dev
$ # In a separate terminal
$ ./git2consul -config pkg/e2e/data/create-config.json -once -debug

This project is using goreleaser. GitHub release creation is automated using Travis CI. New releases are automatically created when new tags are pushed to the repo.

$ TAG=v0.0.2 make tag

How to manually create a release without relying on Travis CI.

$ TAG=v0.0.2 make tag
$ GITHUB_TOKEN=xxx make clean release

See LICENSE for details.

See ACKNOWLEDGEMENT.md for details.

See CODE_OF_CONDUCT.md for details.