Harness Open Source (Drone) — Dependencies#

Module info#

• Module: github.com/harness/gitness
• Go version: 1.25.8
• Direct dependencies: ~106
• Indirect dependencies: ~464 (go.sum has 1,141 lines = ~570 unique module entries; ~106 are direct)

Dependency categories#

Core infrastructure#

• github.com/rs/zerolog — Structured, zero-allocation logging; the primary logger throughout app/
• github.com/sirupsen/logrus — Secondary logger, present due to Drone runner ecosystem deps
• github.com/go-logr/logr + github.com/go-logr/zerologr — logr bridge shim so zerolog satisfies controller-runtime’s logger interface
• github.com/kelseyhightower/envconfig — Environment-variable config parsing (config structs tagged with envconfig:)
• github.com/joho/godotenv — .env file loading for local development
• github.com/pelletier/go-toml/v2 — TOML config format support
• github.com/google/wire — Compile-time dependency injection; central to the 2,500-file codebase (see cmd/gitness/wire_gen.go)
• gopkg.in/alecthomas/kingpin.v2 — CLI framework (notably not Cobra; inherited from the classic Drone era)
• github.com/gorhill/cronexpr — Cron expression parsing for pipeline scheduling
• cloud.google.com/go/profiler — Continuous profiling integration with GCP Cloud Profiler
• github.com/posthog/posthog-go — Product analytics / usage telemetry
• github.com/prometheus/client_golang — Prometheus metrics exposition
• github.com/fatih/color + github.com/mattn/go-isatty — Colored CLI output with TTY detection

Networking/HTTP#

• github.com/go-chi/chi/v5 — Primary HTTP router for all REST API endpoints
• github.com/go-chi/cors — CORS middleware for the REST API
• github.com/gorilla/mux — Secondary router used by the OCI registry subsystem (registry/)
• github.com/unrolled/secure — Security header middleware (HSTS, XSS, CSP)
• github.com/gliderlabs/ssh — Native SSH server for git-over-SSH access
• github.com/golang-jwt/jwt/v5 — JWT issuance and validation for authentication
• golang.org/x/oauth2 — OAuth2 flows for SCM provider integrations
• google.golang.org/api — Google API client (Drive, GCS, etc.)
• github.com/sercand/kuberesolver/v5 — Kubernetes-aware DNS resolver for gRPC load balancing
• github.com/ProtonMail/go-crypto — OpenPGP/GPG support for verified git commits
• golang.org/x/crypto — TLS, SSH, and bcrypt primitives
• golang.org/x/net — Extended networking (HTTP/2, DNS, etc.)
• gopkg.in/mail.v2 — Email sending (notifications, invites)

Data/Storage#

• github.com/jmoiron/sqlx — SQL query scanning with struct tags; the primary DB access layer
• github.com/Masterminds/squirrel — SQL query builder for dynamic queries
• github.com/lib/pq — PostgreSQL driver (libpq-based)
• github.com/jackc/pgx/v5 — Pure-Go PostgreSQL driver (used alongside lib/pq for specific pgx features)
• github.com/jackc/pgerrcode — PostgreSQL error code constants for constraint handling
• github.com/mattn/go-sqlite3 — SQLite driver (CGo) for single-node / development deployments
• github.com/golang-migrate/migrate/v4 — Schema migration runner (supports both Postgres and SQLite)
• github.com/maragudk/migrate — Secondary migration library (used in registry/)
• github.com/go-redis/redis/v8 — Redis client for caching and pub/sub
• github.com/go-redsync/redsync/v4 — Redis-backed distributed mutex (used in lock/)
• github.com/hashicorp/golang-lru/v2 — In-memory LRU cache (git objects, ACL results)
• cloud.google.com/go/storage — Google Cloud Storage for blob/artifact storage
• github.com/aws/aws-sdk-go — AWS SDK for S3-compatible artifact storage
• github.com/djherbis/buffer + github.com/djherbis/nio/v3 — Async pipe buffers for git pack-stream handling
• oras.land/oras-go/v2 — OCI Artifact push/pull (ORAS) for the artifact registry
• github.com/opencontainers/go-digest + github.com/opencontainers/image-spec — OCI content addressability
• github.com/distribution/distribution/v3 — Docker registry v2 protocol implementation
• github.com/docker/distribution — Legacy Docker distribution (transitional; used by runner deps)
• github.com/guregu/null — Nullable SQL types (null.String, null.Int) for schema mapping
• github.com/klauspost/compress — High-performance compression for OCI layer handling
• github.com/sassoftware/go-rpmutils — RPM package parsing for the artifact registry

Drone / CI pipeline heritage#

• github.com/drone-runners/drone-runner-docker — The Docker pipeline runner (executes steps in containers)
• github.com/drone/drone-go — Drone API client SDK
• github.com/drone/drone-yaml — Drone pipeline YAML parser and linter
• github.com/drone/funcmap — Template helper functions for pipeline variable substitution
• github.com/drone/go-convert — Converts between Drone YAML versions and Harness pipeline format
• github.com/drone/go-generate — Pipeline YAML generation utilities
• github.com/drone/go-scm — Multi-provider SCM abstraction (GitHub, GitLab, Gitea, Bitbucket, etc.) — one of the most reused Drone libraries in the ecosystem
• github.com/drone/runner-go — Shared runner framework (polling, step execution, logging)
• github.com/drone/spec — Drone pipeline spec definitions
• go.starlark.net — Starlark scripting language for pipeline definitions (like Bazel’s BUILD files)
• github.com/google/go-jsonnet — Jsonnet templating for pipeline configuration

API / Serialization#

• github.com/swaggest/openapi-go — OpenAPI 3.x spec generation from Go handlers (Harness uses this for the public API)
• github.com/swaggest/swgui — Embedded Swagger UI
• github.com/swaggo/http-swagger + github.com/swaggo/swag — Alternative Swagger 2.0 docs (used in some sub-areas)
• github.com/getkin/kin-openapi — OpenAPI spec validation at runtime
• github.com/oapi-codegen/runtime — Runtime types for oapi-codegen-generated clients
• github.com/swaggest/jsonschema-go — JSON Schema type generation
• github.com/tidwall/jsonc — JSON with comments (for relaxed config files)
• gopkg.in/yaml.v3 — YAML marshaling (pipeline files, config)
• github.com/pelletier/go-toml/v2 — TOML (config alternative)
• github.com/yuin/goldmark — Markdown-to-HTML rendering (README display)
• golang.org/x/text — Unicode / text normalization

Testing#

• github.com/stretchr/testify — Universal assertion library (assert, require, mock)
• github.com/onsi/ginkgo/v2 + github.com/onsi/gomega — BDD-style tests (primarily in registry/)
• github.com/google/go-cmp — Deep equality comparison for complex struct diffs
• github.com/tsenart/vegeta/v12 — HTTP load testing library (performance benchmarks)

Other notable#

• github.com/google/uuid + github.com/rs/xid + github.com/matoous/go-nanoid (both v1 and v2) + github.com/dchest/uniuri — Four different ID generation libraries, each adopted by different subsystems at different times; suggests organic growth without ID strategy consolidation
• github.com/Masterminds/semver/v3 + github.com/coreos/go-semver — Two semver libraries serving different subsystems
• github.com/hashicorp/go-multierror + go.uber.org/multierr — Two multi-error aggregation libraries
• github.com/pkg/errors — Legacy error wrapping (pre-Go 1.13 style; kept for drone/* compatibility)
• github.com/zricethezav/gitleaks/v8 — Secret scanning for git push protection
• github.com/harness/harness-migrate — Data migration from Drone/GitHub/GitLab to Harness Open Source
• github.com/bmatcuk/doublestar/v4 — Glob pattern matching (.gitignore-style path rules)
• golang.org/x/sync — errgroup, singleflight for concurrent operations
• golang.org/x/exp — Experimental generics (slices, maps) before stdlib promotion
• golang.org/x/mod — Go module path parsing

Stdlib reliance#

The project makes heavy use of stdlib alongside third-party packages. In the app/ subtree alone:

• context — 716 file-level imports (present in nearly every file)
• fmt — 582 imports
• net/http — 364 imports
• time — 205 imports
• encoding/json — 184 imports
• strings — 129 imports
• errors — 87 imports (modern errors.Is/errors.As style)
• io — 47 imports
• database/sql — 16 imports (mostly via sqlx on top)

The project uses stdlib’s net/http server, database/sql interfaces, and io.Reader/io.Writer contracts pervasively. Third-party libs layer on top of stdlib rather than replacing it. The dual context+errors pattern (stdlib-first) is dominant.

Shared dependencies#

Dependencies commonly shared with other projects in the 50-project research set:

Vendoring#

No vendor directory. The project relies on the Go module proxy and local replace directives only. The one exception is:

replace github.com/harness/gitness/registry => ./registry

This replaces the registry sub-module with a local path, enabling the OCI registry to be developed as a semi-independent module while still being compiled into the monolithic binary. This is a workspace-style pattern without a full go.work file.

Notable dependency decisions#

1. Kingpin over Cobra — The CLI uses kingpin.v2 rather than Cobra, reflecting the project’s Drone lineage. This is unusual in 2024+ Go projects where Cobra dominates. It creates minor friction when users expect --help flag behavior consistent with Cobra-based tools.

2. Two PostgreSQL drivers in parallel — Both lib/pq (CGo) and jackc/pgx/v5 (pure Go) are direct dependencies. lib/pq is the primary database/sql driver used by sqlx; pgx/v5 is used directly for specific features (LISTEN/NOTIFY, pgx’s bulk copy). This represents an in-progress migration that hasn’t fully landed.

3. Four ID generation libraries — uuid, xid, go-nanoid (×2), and uniuri all generate unique identifiers but were adopted by different teams at different times. The duplication reflects the cost of platform consolidation across formerly separate subsystems.

4. Drone ecosystem lock-in — Eight github.com/drone/* packages are direct dependencies. This gives the project access to battle-tested CI primitives but means the pipeline subsystem is tightly coupled to Drone’s ecosystem choices (YAML schema, runner protocol, SCM abstraction model).

5. Two semver and two multi-error libraries — Masterminds/semver and coreos/go-semver coexist, as do hashicorp/go-multierror and uber/multierr. These duplicates arise because different sub-modules (OCI registry vs. core app) were developed independently and brought their own preferences, then merged without rationalization.

6. Starlark as a scripting language — Adding go.starlark.net as a direct dependency is a deliberate architectural choice to use Starlark (Python-like, deterministic, sandboxed) rather than Go templates or Jsonnet for complex pipeline generation. It signals aspiration toward a programmable CI model similar to Bazel.

7. OpenAPI tooling proliferation — Three distinct Swagger/OpenAPI packages (swaggest/openapi-go, swaggo/swag, getkin/kin-openapi) are all direct deps, suggesting the API documentation strategy has evolved over time and different parts of the codebase adopted different tools without unification.