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/goharbor/harbor 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
• 40+ active contributors
• Distributed ownership (top contributor 17% 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 goharbor/harbor repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/goharbor/harbor.

What it runs against: a local clone of goharbor/harbor — 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 goharbor/harbor | 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 | 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 goharbor/harbor. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/goharbor/harbor.git
#   cd harbor
#
# 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 goharbor/harbor and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "goharbor/harbor(\\.git)?\\b" \\
  && ok "origin remote is goharbor/harbor" \\
  || miss "origin remote is not goharbor/harbor (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"

# 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/goharbor/harbor"
  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).

Harbor is an open-source container registry that extends Docker Distribution with enterprise features like image signing, vulnerability scanning, replication, and role-based access control. It solves the problem of needing a secure, auditable, and manageable private registry for cloud-native workloads closer to build and run environments, reducing transfer latency and improving supply chain security. Monolithic microservices architecture: core Go services (api/, core/) handle registry logic; TypeScript frontend in src/ provides web UI; Python worker services handle async tasks (scanning, replication); RobotFramework tests in tests/ validate end-to-end flows. Configuration-driven via docker-compose (contrib/docker-compose/) or Helm charts; API defined in api/v2.0/swagger.yaml with OpenAPI spec validation.

DevOps engineers, platform teams, and security operators who need to run a self-hosted container registry with compliance requirements (audit logs, access control, image scanning, signing). Organizations adopting Kubernetes and microservices that need fine-grained control over image provenance and vulnerability management.

Highly mature and production-ready. Harbor is a CNCF-hosted project with extensive CI/CD coverage (.github/workflows/ shows 10+ automated workflows including conformance tests), comprehensive test suites across Go/Python/RobotFramework, and active development. The codebase is 6MB+ of Go with well-established release processes (RELEASES.md, VERSION file, release templates) and monthly community calls indicating strong governance.

Standard open source risks apply.

Active development with recent workflow additions (api-schema-check.yml, codeql-analysis.yml show security-focused CI improvements). Dependabot configuration suggests dependency updates are automated and monitored. Nightly Trivy scans indicate ongoing vulnerability scanning focus. The presence of conformance_test.yml suggests work on OCI Distribution spec compliance.

git clone https://github.com/goharbor/harbor.git && cd harbor && make install && make start (check Makefile for exact targets). Docker Compose option: see contrib/backup-restore/ and docker-compose patterns. Harbor requires PostgreSQL; review contrib/ for deployment patterns or use docker-compose setup.

Daily commands: make install (compiles Go binaries); make start (launches services via Docker Compose); check Makefile for specific targets. For development: go build in relevant src-dirs, npm/yarn for TypeScript components. Requires Docker daemon running and PostgreSQL accessible. Review docker-compose.yml equivalents in contrib/.

• api/v2.0/swagger.yaml: OpenAPI specification for entire REST API; source of truth for API contract and code generation targets
• Makefile: Build and development entry point with all compilation, test, and deployment targets
• .github/workflows/CI.yml: Primary continuous integration pipeline defining test suites, build steps, and quality gates
• docker-compose.yml: Local development environment orchestration (if present in root) or check contrib/ for patterns
• VERSION: Single source of truth for release versioning across all components
• CONTRIBUTING.md: Contribution guidelines, code style, and PR process specific to this project
• src/core/: Main Go backend implementation containing registry logic, access control, replication
• tests/: RobotFramework end-to-end tests validating complete workflows and OCI conformance

API changes: edit api/v2.0/swagger.yaml first (validated by api-schema-check.yml workflow), implement in corresponding Go handler files under src/core/. UI changes: TypeScript in src/ (likely under src/app/, src/components/). Backend logic: Go packages under src/ (replication logic, scanning integration, access control). Tests: add .robot files in tests/ for integration tests, Go *_test.go files for unit tests.

1. PostgreSQL must be running and accessible before services start (check docker-compose for connection config). 2) OCI Distribution spec compliance is tested via conformance_test.yml workflow — deviations will break compatibility with standard clients. 3) Image signing and scanning require integration with external services (Notary, Trivy) — configuration in config files not in repo root. 4) Go version constraints in Makefile/workflows may conflict with system Go; use version specified in .github/workflows/CI.yml. 5) Static assets in TypeScript build must be regenerated after UI changes; check Makefile for npm/yarn build targets. 6) API schema validation is enforced in CI (.github/workflows/api-schema-check.yml) — swagger.yaml changes require regenerating Go code.

• OCI Distribution Spec Compliance — Harbor must conform to OCI Image Spec v1.0 to be interoperable with standard container tools (docker, podman, containerd); conformance_test.yml workflow validates this
• Role-Based Access Control (RBAC) — Harbor implements project-scoped permissions and robot accounts for fine-grained access; understanding RBAC model is critical for security features and API changes
• Content Addressability via SHA256 Digests — Container images are addressed by content hash (digest) not just tags; this immutability is core to secure image references and replication logic
• Image Signing and Notary Integration — Harbor integrates Docker Content Trust (Notary) for signing images; understanding key management and verification flows is essential for security-related features
• Registry Replication and Image Transfer — Harbor can replicate images between registries with filter policies; the replication worker and transfer mechanisms are non-trivial distributed systems components
• Webhook Event Model for Audit Logging — Harbor emits webhook events for audit trails and external system integration; understanding the event schema and firing points is critical for compliance features
• Database Schema Versioning with Migrations — PostgreSQL migrations must be versioned and backward-compatible; Harbor uses a migration strategy to evolve the schema — changes require migrations in the correct directory structure

• distribution/distribution — The upstream Docker Registry v2 implementation that Harbor extends with additional enterprise features
• theupdateframework/notary — Companion project for image signing and content trust validation that Harbor integrates with
• aquasecurity/trivy — Vulnerability scanner that Harbor uses for image scanning and compliance checks
• cri-o/cri-o — CRI implementation that works with Harbor registries in Kubernetes environments
• goharbor/harbor-helm — Official Helm charts repository for deploying Harbor to Kubernetes (referenced in README badges)

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 database migrations in PostgreSQL

The repo has migrations at make/migrations/postgresql/ but lacks visible integration tests to verify migrations work correctly across versions. This is critical for a registry that stores state - broken migrations cause data loss or deployment failures. New contributors could add a GitHub Action workflow that spins up PostgreSQL, runs migrations forward and backward, and validates schema integrity.

• [ ] Create .github/workflows/db-migration-test.yml to test PostgreSQL migrations
• [ ] Add migration validation scripts in make/migrations/postgresql/
• [ ] Test forward migrations from initial schema through all versions
• [ ] Test rollback functionality for each migration
• [ ] Validate schema consistency after migrations complete
• [ ] Document migration testing process in docs/

Add Swagger/OpenAPI validation workflow for api/v2.0/swagger.yaml

The repo has an API schema at api/v2.0/swagger.yaml and references 'api-schema-check.yml' in workflows, but the actual workflow file is not visible in the file structure. This is a gap - the Swagger file should be linted, validated against OpenAPI specs, and checked for breaking changes. A contributor could implement comprehensive schema validation similar to what api/v2.0/README.md likely documents.

• [ ] Verify .github/workflows/api-schema-check.yml exists and is complete
• [ ] Add OpenAPI 3.0 schema validation using swagger-cli or spectral
• [ ] Integrate with existing .spectral.yaml configuration
• [ ] Add breaking change detection between versions
• [ ] Validate API examples in swagger.yaml against actual endpoints
• [ ] Add documentation in api/v2.0/README.md about schema validation process

Implement end-to-end tests for backup/restore functionality in contrib/backup-restore/

Harbor provides backup and restore scripts at contrib/backup-restore/harbor-backup and harbor-restore, but there are no visible E2E tests validating they work correctly. This is high-risk - data loss scenarios require rigorous testing. A contributor could create a workflow that deploys Harbor, backs up data, simulates failure, and restores to verify integrity.

• [ ] Create .github/workflows/backup-restore-test.yml for E2E testing
• [ ] Add test scripts in contrib/backup-restore/ to validate backup file integrity
• [ ] Test backup/restore with various data scenarios (images, artifacts, metadata)
• [ ] Verify consistency of restored Harbor state against backup source
• [ ] Add documentation in contrib/backup-restore/README.md with test results
• [ ] Include disaster recovery runbook validation

• Add missing test coverage for error paths in src/core/config/ package — many configuration loading scenarios lack unit test coverage (.go test files are sparse); start with config validation error cases
• Document the relationship between swagger.yaml OpenAPI types and generated Go model files — many junior contributors struggle with API contract-to-implementation mapping; update CONTRIBUTING.md with walkthrough
• Create TypeScript component storybook or documentation for src/ UI components — no obvious Storybook setup exists; would help frontend contributors understand reusable component patterns

Harbor demonstrates a mature security posture with established CI/CD pipelines, automated dependency management via Dependabot, CodeQL analysis, and CII Best Practices certification. However, several areas require attention: the Security.md policy is incomplete, dependency contents are not provided for verification, and database/API security patterns cannot be fully assessed without source code review. The project follows security best practices but should prioritize completing security documentation, ensuring strict database access controls, and maintaining rigorous input validation across all API endpoints handling untrusted user data.

• Medium · Database Migration Files Lack Access Controls — make/migrations/postgresql/. Multiple SQL migration files are present in the repository (make/migrations/postgresql/*.sql). While these files themselves may not contain secrets, they represent critical schema changes that could be exploited if database access controls are misconfigured. The presence of migration files in version control should be accompanied by strict database access policies. Fix: Ensure database migration execution is restricted to authorized deployment pipelines only. Implement principle of least privilege for database users. Consider using a dedicated migration service account with minimal required permissions.
• Medium · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears truncated and incomplete. The vulnerability disclosure and reporting process documentation is cut off mid-sentence, which may lead to unclear security reporting procedures and potential delays in handling security issues. Fix: Complete and fully document the security reporting process, including: clear contact information, expected response times, disclosure timeline, and links to security contact details. Ensure the policy is easily discoverable.
• Medium · Potential Insecure Dependency Management — go.mod, go.sum (not provided). The provided dependency/package file content is empty. Without visibility into Go dependencies, it's impossible to verify if known vulnerable dependencies are in use. Harbor is a critical infrastructure component that requires rigorous dependency scanning. Fix: Implement automated dependency scanning using tools like Dependabot (already configured in .github/dependabot.yml), OWASP Dependency-Check, or Snyk. Regularly audit and update dependencies. Pin versions for critical libraries.
• Low · Configuration Template File Security — make/harbor.yml.tmpl. The harbor.yml.tmpl file is a configuration template that may contain security-sensitive configuration options. If this template includes example credentials or default insecure settings, it could lead to misconfiguration in deployments. Fix: Ensure the template uses placeholder values (e.g., 'CHANGE_ME', '<your-password>') for all sensitive fields. Document required security configurations prominently. Include warnings about default insecure settings.
• Low · Missing Input Validation Patterns Visibility — api/v2.0/ (API endpoints). While no actual source code is provided for analysis, Harbor as a registry handles OCI artifacts and image metadata. Without reviewing the codebase, SQL injection and XSS vulnerabilities cannot be ruled out, particularly in the API endpoints handling user-supplied content. Fix: Ensure all user inputs are validated and sanitized. Use parameterized queries for all database operations. Implement output encoding for API responses. Conduct regular static security analysis using CodeQL (already configured).
• Low · Docker Image Build Security — .dockerignore. The .dockerignore file exists but its contents are not visible. Improper Docker build context exclusion could leak sensitive files into container images. Fix: Verify .dockerignore excludes: .git, .env files, credentials, private keys, and build artifacts. Use multi-stage builds to minimize final image size and attack surface.
• Low · Unclear Supply Chain Security for Release Artifacts — .github/workflows/publish_release.yml. The publish_release.yml workflow exists but without examining the workflow definition, it's unclear if release artifacts are signed and if provenance is validated. OCI conformance and supply chain security are critical for a trusted registry. Fix: Sign all release artifacts and publish signatures. Implement SLSA framework compliance. Use artifact attestation (Sigstore/Cosign). Document the release process and verification steps for users.

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.