If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/jaegertracing/jaeger shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 18 active contributors
• Distributed ownership (top contributor 26% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live jaegertracing/jaeger repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/jaegertracing/jaeger.

What it runs against: a local clone of jaegertracing/jaeger — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in jaegertracing/jaeger | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of jaegertracing/jaeger. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/jaegertracing/jaeger.git
#   cd jaeger
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of jaegertracing/jaeger and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "jaegertracing/jaeger(\\.git)?\\b" \\
  && ok "origin remote is jaegertracing/jaeger" \\
  || miss "origin remote is not jaegertracing/jaeger (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "Makefile" \\
  && ok "Makefile" \\
  || miss "missing critical file: Makefile"
test -f ".github/workflows/ci-orchestrator.yml" \\
  && ok ".github/workflows/ci-orchestrator.yml" \\
  || miss "missing critical file: .github/workflows/ci-orchestrator.yml"
test -f "cmd" \\
  && ok "cmd" \\
  || miss "missing critical file: cmd"
test -f ".golangci.yml" \\
  && ok ".golangci.yml" \\
  || miss "missing critical file: .golangci.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/jaegertracing/jaeger"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Jaeger is a CNCF-graduated distributed tracing platform that instruments applications to collect, store, and visualize traces across microservices. It accepts traces via OpenTelemetry SDKs over OTLP (gRPC on port 4317, HTTP on port 4318), routes them through a Collector component, persists them in pluggable storage backends (Elasticsearch, Cassandra, Badger, ClickHouse, OpenSearch, in-memory), and exposes a Query service with a React-based UI (port 16686) for trace inspection and service dependency analysis. Monorepo with layered architecture: cmd/ contains binaries (jaeger, collector, query, ingester), pkg/ holds core logic (storage, collector, query, sampler, metrics), model/ contains trace data structures, and storage plugins live in storage/. CI orchestration uses three-stage GitHub Actions (ci-orchestrator-stage1/2/3.yml) that fan out to specialized e2e workflows per backend (elasticsearch, cassandra, clickhouse, etc.). UI lives in separate jaegertracing/jaeger-ui repo.

DevOps engineers, SREs, and platform teams operating microservices who need end-to-end visibility into request latency, errors, and service dependencies. Backend developers instrumenting Go, Python, and Node.js applications also contribute heavily. Enterprise users running Jaeger v2 in Kubernetes clusters benefit from the plugin architecture for proprietary storage.

Production-ready and actively developed. Graduated CNCF project (October 2019) with extensive CI/CD (30+ GitHub Actions workflows), 3.3M lines of Go code, comprehensive test coverage (codecov.yml present), and v2 release with breaking changes recently shipped. The monorepo shows continuous development across multiple storage backends and release automation.

Low risk for mature use cases; moderate risk for custom storage plugins. Dependency surface is large (30+ e2e test workflows suggest complex integration matrix), but FOSSA scanning and OpenSSF scorecard badges indicate compliance rigor. The Makefile and Go Template build system is mature. Main risk: plugin API stability across major versions (v2 introduced breaking changes per README).

Active development on v2 with plugin-based architecture. Recent focus: multi-backend storage (ClickHouse, OpenSearch), Kafka ingestion, tail-based sampling, gRPC improvements, and Kubernetes/OTEL integration. Multiple e2e test pipelines validate against real Cassandra, Elasticsearch, Badger, and other stores. PR quota management and AI sidecar (ci-ai-sidecar-gemini.yml) suggest heavy CI automation.

git clone https://github.com/jaegertracing/jaeger.git
cd jaeger
make build  # Uses Makefile (Makefile present in root)
docker run --rm --name jaeger -p 16686:16686 -p 4317:4317 -p 4318:4318 jaegertracing/jaeger:latest
# Access UI at http://localhost:16686

Daily commands:

make build                          # Compiles all binaries
make docker-build-all              # Builds Docker images
./bin/jaeger-all-in-one             # All-in-one (includes UI, collector, query, storage)
# Or separately:
./bin/jaeger-collector &
./bin/jaeger-query &
./bin/jaeger-ingester &

• README.md — Entry point for understanding Jaeger's purpose, architecture, and quick start; defines the project's scope and user journey
• Makefile — Build orchestration for all components; essential to understand how to compile, test, and deploy the entire distributed tracing system
• .github/workflows/ci-orchestrator.yml — Primary CI/CD pipeline orchestrating all test stages and builds; critical for understanding release and validation processes
• cmd — Root directory containing all executable entry points (collectors, query service, agents); understanding the cmd structure is foundational
• .golangci.yml — Go linter configuration enforcing code quality standards across the monorepo; defines what passes code review
• .github/scripts/package.json — CI automation dependencies and test configuration; required for understanding GitHub Actions automation and PR management
• CONTRIBUTING.md — Contributor guidelines defining workflow, testing requirements, and development standards for the distributed tracing platform

Add a New E2E Test for a Storage Backend

1. Create new workflow file following naming convention ci-e2e-<backend>.yml in .github/workflows/ (.github/workflows/ci-e2e-elasticsearch.yml)
2. Define job matrix with appropriate backend setup (docker-compose, services section) and test command (.github/workflows/ci-e2e-elasticsearch.yml)
3. Add workflow dispatch trigger and schedule (cron) for periodic testing (.github/workflows/ci-e2e-elasticsearch.yml)
4. Update orchestrator workflow to include new backend test in ci-orchestrator.yml workflow_run dependencies (.github/workflows/ci-orchestrator.yml)

Add a New CLI Tool or Utility Command

1. Create new directory under cmd/ with structure: cmd/mytool/app/ for application logic (cmd/anonymizer/app)
2. Implement main executable file and package-scoped functions following anonymizer pattern (cmd/anonymizer/app/anonymizer/anonymizer.go)
3. Add corresponding _test.go file and package_test.go for test fixtures in same structure (cmd/anonymizer/app/anonymizer/anonymizer_test.go)
4. Create Dockerfile in cmd/mytool/ root directory for containerized distribution (cmd/anonymizer/Dockerfile)
5. Add make target in Makefile and CI build workflow for automated releases (Makefile)

Enforce New Code Quality Rules Across Monorepo

1. Update .golangci.yml to add new linter or modify existing linter configuration thresholds (.golangci.yml)
2. Run linting locally via Makefile target to identify violations in existing code (Makefile)
3. Add linting step to ci-lint-checks.yaml workflow if new linter requires special handling (.github/workflows/ci-lint-checks.yaml)
4. Document new rule in CONTRIBUTING.md Code Style section for developer awareness (CONTRIBUTING.md)

Modify CI/CD Pipeline or Add Deployment Stage

1. Identify appropriate orchestrator stage file (1, 2, or 3) or create new stage workflow (.github/workflows/ci-orchestrator-stage1.yml)
2. Define job with appropriate triggers (needs, on.workflow_run) and permissions for deployment (.github/workflows/ci-deploy-demo.yml)
3. Use GitHub Actions from .github/actions/ for reusable setup logic (setup-go, setup-node.js) (.github/actions/setup-go/action.yml)
4. Register new workflow in main ci-orchestrator.yml and update dependency graph if needed (.github/workflows/ci-orchestrator.yml)

• Go — Primary language for Jaeger backend components; enables high-performance, lightweight distributed tracing collectors and query services with minimal resource overhead
• GitHub Actions — Native CI/CD platform for monorepo; orchestrates multi-stage testing (unit, e2e, lint) across multiple storage backends and Go versions with dependency management
• Docker & Container Images — Enables all-in-one deployment, demo distribution (HotROD), and component isolation; supports multiple storage backend configurations in e2e tests
• Multiple Storage Backends (Elasticsearch, Cassandra, Badger, ClickHouse, OpenSearch) — Provides flexibility for production deployments; each backend tested independently in e2e pipelines to ensure data consistency and query correctness
• Node.js/JavaScript for CI Automation — Enables custom GitHub Actions automation (PR quota management, result publishing, stale PR detection) without heavyweight scripting dependencies

• Monorepo
  • Why: undefined
  • Consequence: undefined

Storage backend connection strings must be pre-configured (Cassandra cluster, Elasticsearch endpoint) before collector starts. OTLP gRPC on 4317 and HTTP on 4318 are hardcoded defaults; custom ports require config rebuild. Docker images are built separately per component (jaeger-collector, jaeger-query) — all-in-one is a convenience wrapper. Tests expect external services running (real Cassandra/ES for e2e); unit tests run in isolation but e2e tests in .github/workflows/ spawn Docker containers. Go 1.x version pinning in actions/setup-go affects build reproducibility.

• Trace sampling — Jaeger's sampler (pkg/sampler/) decides which traces to keep to reduce storage/costs — adaptive and probabilistic samplers are core to production scaling
• Span baggage — Cross-cutting context (user ID, request ID) propagated across service boundaries in trace metadata — essential for correlation in microservices
• Service dependency inference — Jaeger builds a directed graph of services from trace spans; UI shows topology without manual registration — enables auto-discovery of microservice architecture
• OpenTelemetry Protocol (OTLP) — gRPC and HTTP endpoints that Jaeger Collector exposes to receive traces from SDKs in a vendor-neutral format — enables multi-backend deployments
• Storage plugin architecture — pkg/storage/storage.go defines an interface allowing pluggable backends (Cassandra, ES, Badger, ClickHouse); new backends inherit common patterns without forking core
• gRPC health check and reflection — Jaeger services expose gRPC health probes for Kubernetes liveness/readiness; reflection aids debugging — critical for containerized deployments
• Tail-based sampling — Advanced sampling strategy in pkg/sampler/ that keeps entire traces of slow/errored requests after collection — reduces noise and preserves signal

• jaegertracing/jaeger-ui — Separate React repository for the Jaeger UI frontend (port 16686) that queries the Jaeger API
• open-telemetry/opentelemetry-go — Official Go SDK that instruments applications to emit traces sent to Jaeger via OTLP
• open-telemetry/opentelemetry-collector — OTEL Collector is a complementary trace router/processor; Jaeger Collector is specialized for Jaeger but both accept OTLP
• prometheus/prometheus — Jaeger exports metrics to Prometheus; common observability stack alongside tracing
• elastic/elasticsearch — Primary storage backend for Jaeger in production deployments; Jaeger storage/es/ adapter abstracts client interactions

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for pr-quota-manager.js GitHub Actions workflow

The pr-quota-manager.js script in .github/scripts/ manages pull request quotas but lacks integration tests that verify it correctly interacts with GitHub API via @octokit/rest. Currently only unit tests exist (pr-quota-manager.test.js). Adding integration tests would validate the script's behavior against real GitHub API patterns and edge cases like API rate limiting, quota calculations, and PR closure logic.

• [ ] Create .github/scripts/pr-quota-manager.integration.test.js with mock GitHub API responses
• [ ] Add tests for quota enforcement scenarios: at-quota, over-quota, and under-quota states
• [ ] Add tests for edge cases like API rate limit responses and malformed PR data
• [ ] Update .github/scripts/package.json to add 'test:integration' script
• [ ] Document integration test setup in .github/scripts/README.md

Add missing GitHub Action for Node.js dependency security scanning

The repo has .github/workflows/dependency-review.yml for general dependency review, but lacks a dedicated workflow for Node.js package vulnerabilities in .github/scripts/. Given that the scripts package has dependencies like @octokit/rest and uses Node >=24, adding a workflow to scan package.json for known vulnerabilities using npm audit or Snyk would improve supply chain security.

• [ ] Create .github/workflows/ci-scripts-npm-audit.yml that runs 'npm audit' on .github/scripts/
• [ ] Configure it to fail on high/critical vulnerabilities and warn on moderate ones
• [ ] Run workflow on pull requests modifying .github/scripts/package.json or .github/scripts/package-lock.json
• [ ] Add workflow status badge to .github/scripts/README.md
• [ ] Document npm audit expectations in CONTRIBUTING.md for the scripts directory

Create unit tests for ci-summary-report-publish.js with full coverage

The ci-summary-report-publish.js script exists in .github/scripts/ but the jest config in package.json lists it in collectCoverageFrom, yet no corresponding .test.js file exists for it. This script appears to publish CI summary reports but lacks test coverage. Adding comprehensive unit tests would document expected behavior and prevent regressions.

• [ ] Create .github/scripts/ci-summary-report-publish.test.js with jest test suite
• [ ] Add tests for report generation logic, GitHub API calls (via mocked @octokit/rest), and error handling
• [ ] Test edge cases: empty reports, malformed data, network failures
• [ ] Ensure coverage meets or exceeds 80% as indicated by existing jest configuration
• [ ] Run 'npm run test:coverage' locally and verify ci-summary-report-publish.js coverage before submitting PR

• Add integration tests for the Badger storage backend in storage/badger/*_test.go — currently minimal coverage compared to Cassandra/ES, good way to learn storage plugin interface
• Extend metrics snapshot verification (ci-verify-metrics-snapshot.yaml) to cover new Prometheus metrics exposed by sampler and ingester — currently incomplete per .github/actions/verify-metrics-snapshot/
• Document storage backend selection matrix in cmd/jaeger/config/ — README snippets exist but a structured guide mapping use-case (high-cardinality / high-throughput / cost) to backend choice is missing

The Jaeger CI scripts package has moderate security posture. Primary concerns include an outdated Jest dependency (30.3.0) which likely contains known vulnerabilities, and a permissive Node.js version constraint (>=24 without upper bound). The project demonstrates good security practices through dependency evaluation policies (documented in SECURITY.md), Apache 2.0 licensing compliance, and use of standard security tools (CodeQL, FOSSA, OpenSSF Scorecard). Immediate actions should focus on updating Jest to a current version, tightening version constraints, and ensuring proper input validation in GitHub Actions scripts that interact with the GitHub API.

• High · Outdated Jest Dependency with Known Vulnerabilities — .github/scripts/package.json - devDependencies.jest. The package.json specifies jest version 30.3.0 as a devDependency. This version is significantly outdated and likely contains multiple known security vulnerabilities. Jest 30.x is several major versions behind current releases (Jest 29/30+ are from 2023-2024). Using outdated test frameworks can introduce supply chain risks. Fix: Update jest to the latest stable version (currently 29.x or later). Run 'npm audit' to identify and fix all known vulnerabilities. Consider using 'npm audit fix' or updating to jest@latest.
• Medium · Permissive Node.js Version Requirement — .github/scripts/package.json - engines.node. The engines field specifies 'node: >=24', which only provides a minimum version constraint without an upper bound. This can allow installation on very new, untested Node.js versions that may have breaking changes or incompatibilities. Best practice is to define a supported range. Fix: Update to a more specific range like 'node: >=20.0.0 <25.0.0' or 'node: ^20.0.0' to prevent unexpected behavior from future Node.js versions.
• Medium · Missing npm Lockfile Verification — .github/scripts/package-lock.json. The presence of package-lock.json is mentioned in the file structure but its content is not provided for analysis. Lockfiles should be committed to version control and verified to prevent dependency confusion attacks and ensure reproducible builds. Fix: Ensure package-lock.json is committed to the repository, kept up-to-date, and verified in CI/CD pipelines. Use 'npm ci' instead of 'npm install' in CI environments.
• Low · Broad Dependency Coverage in Jest Configuration — .github/scripts/package.json - jest.collectCoverageFrom. The jest configuration in package.json specifies collectCoverageFrom for pr-quota-manager.js and ci-summary-report-publish.js. While this is reasonable, there's no indication of coverage thresholds being enforced, which could allow low-quality test coverage to be merged. Fix: Add coverage threshold requirements to the jest configuration, e.g., 'coverageThreshold': { 'global': { 'branches': 80, 'lines': 80 } }.
• Low · Insufficient Input Validation Documentation — .github/scripts/ - GitHub Actions scripts. GitHub Actions scripts (ci-summary-report-publish.js, pr-quota-manager.js, waiting-for-author.js) interact with GitHub API. Without visible input sanitization/validation code, there's a potential risk of injection attacks if user inputs or environment variables are not properly validated before use with @octokit/rest. Fix: Ensure all inputs from GitHub API responses and environment variables are validated and sanitized before use. Review scripts for safe handling of user-supplied data. Add ESLint rules to catch potential issues.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.