LabKit is minimalist library to provide functionality for Go services at GitLab.

---

import (
	"gitlab.com/gitlab-org/labkit/correlation"
)

import (
	logkit "gitlab.com/gitlab-org/labkit/log"
)

import (
	"gitlab.com/gitlab-org/labkit/mask"
)

import (
	"gitlab.com/gitlab-org/labkit/metrics"
)

import (
	"gitlab.com/gitlab-org/labkit/monitoring"
)

This package is used for checking whether a binary has been properly compiled with FIPS support.

import (
	"gitlab.com/gitlab-org/labkit/fips"
)

import (
	"gitlab.com/gitlab-org/labkit/fields"
)

// fields.GitLabUserID - returns the constant field name you should use to represent this data.

Anyone can contribute!

Please be aware of the following architectural guidelines.

• LabKit is a library, not an application, and as such, we value compatibility highly.
• Public APIs in LabKit should be backward compatible. This should be done by making APIs forward extensible.
  • Add methods, but do not add (non-optional) parameters to existing methods.
  • Use Functional Options where possible.

• APIs should have an intuitive interface.
• Spend time ensuring thinking about what the best interface is.
• Include excellent godocs, including package documentation in doc.go.

• Be extremely careful about the dependencies your packages include. Be prepared to justify any dependencies you bring into a package.
  • If not users will require a dependency, consider including it in a subpackage (e.g. gitlab.com/gitlab-org/labkit/correlation/grpc), especially if the dependency is large or has a deep dependency tree of it's own.
• Be even more careful about the dependencies that you expose through the API of a package.
• Follow this rule: packages can depend on their parent packages, but not their siblings or children.
  • If required, declare common models in the root package.

Taken from A Philosophy of Software Design, by John Ousterhout. This book is recommended reading.

• Modules should be deep.
• Interfaces should be designed to make the most common usage as simple as possible.
• Separate general-purpose and special-purpose code.
• Design it twice.
• Comments should describe things that are not obvious from the code.

Please assign your MR to a reviewer for a first review, followed by a maintainer review.

Currently, the reviewers are:

1. @reprazent

The maintainers are:

1. @andrewn
2. @igorwwwwwwwwwwwwwwwwwwww
3. @jdrpereira
4. @sxuereb

LabKit uses semantic releases. Please use the Conventional Commits commit format.

A new release should only be created when there is a new user-facing feature or a bug fix. CI, docs, and refactoring shouldn't result in a new release unless it's a big change.