Add open-source gocat

Co-authored-by: Anton Antonov <[email protected]>
Co-authored-by: Bozhidar Gorov <[email protected]>
Co-authored-by: Daniel Lyubomirov <[email protected]>
Co-authored-by: Svetlozar Dimitrov <[email protected]>

.gitignore

@@ -0,0 +1,15 @@
+# Binaries for programs and plugins
+*.exe
+*.exe~
+*.dll
+*.so
+*.dylib
+
+# Test binary, build with `go test -c`
+*.test
+
+# Output of the go coverage tool, specifically when used with LiteIDE
+*.out
+
+.idea
+/gocat

.golangci.yml

@@ -0,0 +1,71 @@
+run:
+  tests: false
+  skip-dirs:
+    # NOTE: Ignore auto-generated files
+    - clients
+    - vendor
+
+  # NOTE: Verify `go.{mod,sum}` is up-to-date by attempting to download dependencies
+  # if anything is missing
+  modules-download-mode: readonly
+
+output:
+  format: colored-line-number
+  print-issued-lines: true
+  print-linter-name: true
+
+linters-settings:
+  errcheck:
+    # report about not checking of errors in type assetions: `a := b.(MyStruct)`;
+    # default is false: such cases aren't reported by default.
+    check-type-assertions: false
+
+  # print linter name in the end of issue text, default is true
+  govet:
+    check-shadowing: true
+  gocyclo:
+    # NOTE: Too-low cyclomatic complexity value
+    # results into worse code design and readability.
+    min-complexity: 25
+  maligned:
+    suggest-new: true
+  dupl:
+    threshold: 100
+  goconst:
+    min-len: 2
+    min-occurrences: 2
+  depguard:
+    list-type: blacklist
+    packages:
+      # logging is allowed only by logutils.Log, logrus
+      # is allowed to use only in logutils package
+      - github.com/sirupsen/logrus
+      # NOTE: Be very, very wary not to use GPL3 software as library
+      - github.com/golangci/golangci-lint
+  misspell:
+    locale: US
+  lll:
+    line-length: 120
+  goimports:
+    local-prefixes: github.com/sumup/gocat
+  gocritic:
+    enabled-tags:
+      - performance
+
+linters:
+  enable-all: true
+  disable:
+    # NOTE: "effective" golang style is full of arguable practices.
+    # We don't need that and besides gofmt does the required minimum of style modifications.
+    - golint
+    # NOTE: Too much false positives
+    - unparam
+    # NOTE: It's a great linter, but gets in the way too often by not being customizable.
+    - gochecknoglobals
+    - depguard
+    - dupl
+issues:
+  exclude-rules:
+    - text: "weak cryptographic primitive"
+      linters:
+        - gosec

.travis.yml

@@ -0,0 +1,23 @@
+sudo: false
+language: go
+go:
+  - 1.12.x
+  - 1.13.x
+os:
+  - linux
+  - osx
+cache:
+  directories:
+    - $HOME/.cache/go-build
+    - $HOME/gopath/pkg/mod
+env:
+  - GO111MODULE=on
+git:
+  depth: 1
+notifications:
+  email: false
+before_script:
+  - curl -sfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.16.0
+script:
+  - golangci-lint run
+  - go test -v ./...

CHANGELOG.md

@@ -0,0 +1,58 @@
+# Version History
+
+## Intro
+
+The version history is motivated by https://semver.org/ and https://keepachangelog.com/en/1.0.0/ .
+
+## Structure
+
+Types of changes that can be seen in the changelog
+
+```
+Added: for new features/functionality.
+Changed: for changes in existing features/functionality.
+Deprecated: for soon-to-be removed features. Removed in the
+Removed: for now removed features.
+Fixed: for any bug fixes.
+Security: in case of vulnerabilities.
+```
+
+## How deprecation of functionality is handled?
+
+tl;dr 1 minor release stating that the functionality is going to be deprecated. Then in the next major - removed.
+
+```
+Deprecating existing functionality is a normal part of software development and
+is often required to make forward progress.
+ 
+When you deprecate part of your public API, you should do two things:
+ 
+(1) update your documentation to let users know about the change,
+(2) issue a new minor release with the deprecation in place.
+Before you completely remove the functionality in a new major
+release there should be at least one minor release
+that contains the deprecation so that users can smoothly transition to the new API
+```
+
+As per https://semver.org/ .
+
+As per rule-of-thumb, moving the project forward is very important,
+  but providing stability is the most important thing to anyone using `gocat`.
+
+Introducing breaking changes under a feature flag can be ok in some cases where new functionality needs user feedback before being introduced in next major release.
+
+## Changelog
+
+Change line format:
+
+```
+* <Change title/PR title/content> ; Ref: <pr link>
+```
+
+## Unreleased (master)
+
+## 1.0.0
+
+### Added
+
+* Open-sourced the project

CODEOWNERS

@@ -0,0 +1 @@
+* @sumup/platform-tooling-squad-codeowners

CODE_OF_CONDUCT.md

@@ -0,0 +1,78 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting one of the project maintainers listed below. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Project Maintainers
+
+*  Anton Antonov  <<[email protected]>>
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,55 @@
+# Contributing
+
+## Prerequisites
+
+* **Signed and verified CLA**
+* Golang 1.12.x
+* (To run linter) https://github.com/golangci/golangci-lint in `$PATH`
+
+## Common commands
+
+### Running the linter
+
+```shell
+> go run mage.go -v lint
+```
+### Running the tests
+
+```shell
+> go run mage.go -v test
+```
+
+### Running the benchmarks
+
+```shell
+> go run mage.go -v bench
+```
+
+### Running the benchmarks and generate graph
+
+```shell
+> go run mage.go -v benchandgraph
+```
+
+## Workflows
+
+### Submitting an issue
+
+1. Check existing issues and verify that your issue is not already submitted.
+ If it is, it's highly recommended to add  to that issue with your reports.
+
+2. Open issue
+
+3. Be as detailed as possible - `go` version, what did you do, 
+what did you expect to happen, what actually happened.
+
+### Submitting a PR
+
+1. Find an existing issue to work on or follow `Submitting an issue` to create one
+ that you're also going to fix. 
+ Make sure to notify that you're working on a fix for the issue you picked.
+1. Branch out from latest `master`.
+1. Code, add, commit and push your changes in your branch.
+1. Make sure that tests and linter(s) pass locally for you.
+1. Submit a PR.
+1. Collaborate with the codeowners/reviewers to merge this in `master`.