labkit

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

Active Pure Nim score 71/100 · last commit 2026-09-05 · 34 stars · tests present · no docs generated

Summary

Latest Version Unknown
License Unknown
CI Status Failing
Stars 34
Forks 45
Open Issues 0
Last Commit 2026-09-05
Downloads 0
Last Indexed 2026-09-06 06:05

Installation

nimble install labkit
choosenim install labkit
git clone https://gitlab.com/gitlab-org/labkit

OS Compatibility

Platform Linux macOS Windows FreeBSD OpenBSD NetBSD Android iOS WASM Embedded
labkit - - - - - - -

Source

Repository https://gitlab.com/gitlab-org/labkit
Homepage https://gitlab.com/gitlab-org/labkit
Registry Source gitlab

README

LabKit 🧪 🔬 🥼 🥽 🧫 🧬 💉

LabKit is GitLab's standardised abstraction layer for platform capabilities in Go services: observability, database connectivity, feature gating, secret management, and service lifecycle. Platform teams publish once; product engineers adopt without reinventing the same infrastructure boilerplate.

Two modules

LabKit is published as two independent Go modules, each with its own go.mod and its own README. Pick the one that matches your project:

Module Import path Status README
v1 gitlab.com/gitlab-org/labkit Security updates only - no planned development; being phased out README-v1.md
v2 gitlab.com/gitlab-org/labkit/v2 Active development - start here for new work v2/README.md

Why two modules?

The two modules reflect a generational shift in the underlying observability and runtime ecosystem rather than a simple version bump:

  • v1 is built on the earlier generation of libraries - OpenTracing, Logrus, and direct Prometheus wiring. It receives security updates only; no new features are planned. v1 is being phased out as v2 is built out and consumers are migrated across.
  • v2 is built on the current generation - OpenTelemetry, the standard library's log/slog, and an app.App lifecycle that wires logging, tracing, metrics, and pluggable components into a common start/shutdown flow. This is where all consumers will eventually land.

They are separate modules so that adopting v2 does not force v1's dependency tree on existing consumers, and so the two can evolve and release independently. All new services and new development should target v2.

Getting started

  • New service? Read the v2 README and start from the app package.
  • Maintaining an existing v1 consumer? See the v1 README for the available packages and usage.

Contributing

See CONTRIBUTING.md for how to contribute.

Please use the Conventional Commits commit format for all changes.

Getting help

Questions or need a hand? Open an issue or reach out in the #labkit Slack channel.