| 1 | # AI Agent Instructions for Kubo |
| 2 | |
| 3 | This file provides instructions for AI coding agents working on the [Kubo](https://github.com/ipfs/kubo) codebase (the Go implementation of IPFS). Follow the [Developer Guide](docs/developer-guide.md) for full details. |
| 4 | |
| 5 | ## Quick Reference |
| 6 | |
| 7 | | Task | Command | |
| 8 | |-------------------|----------------------------------------------------------| |
| 9 | | Tidy deps | `make mod_tidy` (run first if `go.mod` changed) | |
| 10 | | Build | `make build` | |
| 11 | | Unit tests | `go test ./... -run TestName -v` | |
| 12 | | Integration tests | `make build && go test ./test/cli/... -run TestName -v` | |
| 13 | | Lint | `make -O test_go_lint` | |
| 14 | | Format | `go fmt ./...` | |
| 15 | |
| 16 | ## Project Overview |
| 17 | |
| 18 | Kubo is the reference implementation of IPFS in Go. Most IPFS protocol logic lives in [boxo](https://github.com/ipfs/boxo) (the IPFS SDK); kubo wires it together and exposes it via CLI and HTTP RPC API. If a change belongs in the protocol layer, it likely belongs in boxo, not here. |
| 19 | |
| 20 | Key directories: |
| 21 | |
| 22 | | Directory | Purpose | |
| 23 | |--------------------|----------------------------------------------------------| |
| 24 | | `cmd/ipfs/` | CLI entry point and binary | |
| 25 | | `core/` | core IPFS node implementation | |
| 26 | | `core/commands/` | CLI command definitions | |
| 27 | | `core/coreapi/` | Go API implementation | |
| 28 | | `client/rpc/` | HTTP RPC client | |
| 29 | | `plugin/` | plugin system | |
| 30 | | `repo/` | repository management | |
| 31 | | `test/cli/` | Go-based CLI integration tests (preferred for new tests) | |
| 32 | | `test/sharness/` | legacy shell-based integration tests | |
| 33 | | `docs/` | documentation | |
| 34 | |
| 35 | Other key external dependencies: [go-libp2p](https://github.com/libp2p/go-libp2p) (networking), [go-libp2p-kad-dht](https://github.com/libp2p/go-libp2p-kad-dht) (DHT). |
| 36 | |
| 37 | ## Go Style |
| 38 | |
| 39 | Follow these Go style references: |
| 40 | |
| 41 | - [Go Code Review Comments](https://go.dev/wiki/CodeReviewComments) |
| 42 | - [Google Go Style Decisions](https://google.github.io/styleguide/go/decisions) |
| 43 | |
| 44 | Specific conventions for this project: |
| 45 | |
| 46 | - check the Go version in `go.mod` and use idiomatic features available at that version |
| 47 | - readability over micro-optimization: clear code is more important than saving microseconds |
| 48 | - prefer standard library functions and utilities over writing your own |
| 49 | - use early returns and indent the error flow, not the happy path |
| 50 | - use `slices.Contains`, `slices.DeleteFunc`, and the `maps` package instead of manual loops |
| 51 | - preallocate slices and maps when the size is known: `make([]T, 0, n)` |
| 52 | - use `map[K]struct{}` for sets, not `map[K]bool` |
| 53 | - receiver names: single-letter abbreviations matching the type (e.g., `s *Server`, `c *Client`) |
| 54 | - run `go fmt` after modifying Go source files, never indent manually |
| 55 | |
| 56 | ### Error Handling |
| 57 | |
| 58 | - wrap errors with `fmt.Errorf("context: %w", err)`, never discard errors silently |
| 59 | - use `errors.Is` / `errors.As` for error checking, not string comparison |
| 60 | - never use `panic` in library code; only in `main` or test helpers |
| 61 | - return `nil` explicitly for the error value on success paths |
| 62 | |
| 63 | ### Canonical Examples |
| 64 | |
| 65 | When adding or modifying code, follow the patterns established in these files: |
| 66 | |
| 67 | - CLI command structure: `core/commands/dag/dag.go` |
| 68 | - CLI integration test: `test/cli/dag_test.go` |
| 69 | - Test harness usage: `test/cli/harness/` package |
| 70 | |
| 71 | ## Building |
| 72 | |
| 73 | Always run commands from the repository root. |
| 74 | |
| 75 | ```bash |
| 76 | make mod_tidy # update go.mod/go.sum (use this instead of go mod tidy) |
| 77 | make build # build the ipfs binary to cmd/ipfs/ipfs |
| 78 | make install # install to $GOPATH/bin |
| 79 | make -O test_go_lint # run linter (use this instead of golangci-lint directly) |
| 80 | ``` |
| 81 | |
| 82 | **Always build with `make build`, never `go build`.** The Makefile injects required `-ldflags` for `CurrentCommit`, `taggedRelease`, and `buildOrigin`. |
| 83 | |
| 84 | If you modify `go.mod` (add/remove/update dependencies), you must run `make mod_tidy` first, before building or testing. Use `make mod_tidy` instead of `go mod tidy` directly, as the project has multiple `go.mod` files. |
| 85 | |
| 86 | If you modify any `.go` files outside of `test/`, you must run `make build` before running integration tests. |
| 87 | |
| 88 | ## Testing |
| 89 | |
| 90 | The full test suite is composed of several targets: |
| 91 | |
| 92 | | Make target | What it runs | |
| 93 | |----------------------|-----------------------------------------------------------------------| |
| 94 | | `make test` | all tests (`test_go_fmt` + `test_unit` + `test_cli` + `test_sharness`) | |
| 95 | | `make test_short` | fast subset (`test_go_fmt` + `test_unit`) | |
| 96 | | `make test_unit` | unit tests with coverage (excludes `test/cli`) | |
| 97 | | `make test_cli` | CLI integration tests (requires `make build` first) | |
| 98 | | `make test_fuse` | FUSE filesystem tests (requires `/dev/fuse` and `fusermount` in PATH) | |
| 99 | | `make test_sharness` | legacy shell-based integration tests | |
| 100 | | `make test_go_fmt` | checks Go source formatting | |
| 101 | | `make -O test_go_lint` | runs `golangci-lint` | |
| 102 | |
| 103 | During development, prefer running a specific test rather than the full suite: |
| 104 | |
| 105 | ```bash |
| 106 | # run a single unit test |
| 107 | go test ./core/... -run TestSpecificUnit -v |
| 108 | |
| 109 | # run a single CLI integration test (requires make build first) |
| 110 | go test ./test/cli/... -run TestSpecificCLI -v |
| 111 | ``` |
| 112 | |
| 113 | ### Environment Setup for Integration Tests |
| 114 | |
| 115 | Before running `test_cli` or `test_sharness`, set these environment variables from the repo root: |
| 116 | |
| 117 | ```bash |
| 118 | export PATH="$PWD/cmd/ipfs:$PATH" |
| 119 | export IPFS_PATH="$(mktemp -d)" |
| 120 | ``` |
| 121 | |
| 122 | - `PATH`: integration tests use the `ipfs` binary from `PATH`, not Go source directly |
| 123 | - `IPFS_PATH`: isolates test data from `~/.ipfs` or other running nodes |
| 124 | |
| 125 | If you see "version (N) is lower than repos (M)", the `ipfs` binary in `PATH` is outdated. Rebuild with `make build` and verify `PATH`. |
| 126 | |
| 127 | ### Running FUSE Tests |
| 128 | |
| 129 | FUSE tests require `/dev/fuse` and `fusermount` in `PATH`. On systems with only fuse3, create a symlink in a temp directory (never use `sudo` to install system-wide): |
| 130 | |
| 131 | ```bash |
| 132 | FUSE_BIN="$(mktemp -d)" && ln -s /usr/bin/fusermount3 "$FUSE_BIN/fusermount" && PATH="$FUSE_BIN:$PATH" make test_fuse |
| 133 | ``` |
| 134 | |
| 135 | Set `TEST_FUSE=1` to make mount failures fatal (CI does this). Without it, tests auto-detect and skip when FUSE is unavailable. |
| 136 | |
| 137 | ### Running Sharness Tests |
| 138 | |
| 139 | Sharness tests are legacy shell-based tests. Run individual tests with a timeout: |
| 140 | |
| 141 | ```bash |
| 142 | cd test/sharness && timeout 60s ./t0080-repo.sh |
| 143 | ``` |
| 144 | |
| 145 | To investigate a failing test, pass `-v` for verbose output. In this mode, daemons spawned by the test are not shut down automatically and must be killed manually afterwards. |
| 146 | |
| 147 | ### Cleaning Up Stale Daemons |
| 148 | |
| 149 | Before running `test/cli` or `test/sharness`, stop any stale `ipfs daemon` processes owned by the current user. Leftover daemons hold locks and bind ports, causing test failures: |
| 150 | |
| 151 | ```bash |
| 152 | pkill -f "ipfs daemon" |
| 153 | ``` |
| 154 | |
| 155 | ### Writing Tests |
| 156 | |
| 157 | - all new integration tests go in `test/cli/`, not `test/sharness/` |
| 158 | - if a `test/sharness` test needs significant changes, remove it and add a replacement in `test/cli/` |
| 159 | - use [testify](https://github.com/stretchr/testify) for assertions (already a dependency) |
| 160 | - use `t.Context()` instead of `context.Background()` in tests |
| 161 | - for Go 1.25+, use `testing/synctest` when testing concurrent code (goroutines, channels, timers) |
| 162 | - reuse existing `.car` fixtures in `test/cli/fixtures/` when possible; only add new fixtures when the test requires data not covered by existing ones |
| 163 | - when writing tests that cover CIDv0 vs CIDv1, always set the CID version explicitly (never rely on defaults); if chunk size matters for the test, also set the chunker explicitly |
| 164 | - always re-run modified tests locally before submitting to confirm they pass |
| 165 | - avoid emojis in test names and test log output |
| 166 | |
| 167 | ## Before Submitting |
| 168 | |
| 169 | Run these steps in order before considering work complete: |
| 170 | |
| 171 | 1. `make mod_tidy` (if `go.mod` changed) |
| 172 | 2. `go fmt ./...` |
| 173 | 3. `make build` (if non-test `.go` files changed) |
| 174 | 4. `make -O test_go_lint` |
| 175 | 5. `go test ./...` (or the relevant subset) |
| 176 | |
| 177 | ## Documentation and Commit Messages |
| 178 | |
| 179 | - after editing CLI help text in `core/commands/`, verify width: `go test ./test/cli/... -run TestCommandDocsWidth` |
| 180 | - config options are documented in `docs/config.md` |
| 181 | - changelogs in `docs/changelogs/`: only edit the Table of Contents and the Highlights section; the Changelog and Contributors sections are auto-generated and must not be modified |
| 182 | - avoid unnecessary line wrapping in `docs/changelogs/*`; let lines be long |
| 183 | - follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) |
| 184 | - keep commit titles short and messages terse |
| 185 | |
| 186 | ## Writing Style |
| 187 | |
| 188 | When writing docs, comments, and commit messages: |
| 189 | |
| 190 | - avoid emojis in code, comments, and log output |
| 191 | - keep an empty line before lists in markdown |
| 192 | - use backticks around CLI commands, paths, environment variables, and config options |
| 193 | |
| 194 | ## PR Guidelines |
| 195 | |
| 196 | - explain what changed and why in the PR description |
| 197 | - include test coverage for new functionality and bug fixes |
| 198 | - run `make -O test_go_lint` and fix any lint issues before submitting |
| 199 | - verify that `go test ./...` passes locally |
| 200 | - when modifying `test/sharness` tests significantly, migrate them to `test/cli` instead |
| 201 | - end the PR description with a `## References` section listing related context, one link per line |
| 202 | - if the PR closes an issue in `ipfs/kubo`, each closing reference should be a bullet starting with `Closes`: |
| 203 | |
| 204 | ```markdown |
| 205 | ## References |
| 206 | |
| 207 | - Closes https://github.com/ipfs/kubo/issues/1234 |
| 208 | - Closes https://github.com/ipfs/kubo/issues/5678 |
| 209 | - https://discuss.ipfs.tech/t/related-topic/999 |
| 210 | ``` |
| 211 | |
| 212 | ## Scope and Safety |
| 213 | |
| 214 | Do not modify or touch: |
| 215 | |
| 216 | - files under `test/sharness/lib/` (third-party sharness test framework) |
| 217 | - CI workflows in `.github/` unless explicitly asked |
| 218 | - auto-generated sections in `docs/changelogs/` (Changelog and Contributors are generated; only TOC and Highlights are human-edited) |
| 219 | |
| 220 | Do not run without being asked: |
| 221 | |
| 222 | - `make test` or `make test_sharness` (full suite is slow; prefer targeted tests) |
| 223 | - `ipfs daemon` without a timeout |
| 224 | |
| 225 | ## Running the Daemon |
| 226 | |
| 227 | Always run the daemon with a timeout or shut it down promptly: |
| 228 | |
| 229 | ```bash |
| 230 | timeout 60s ipfs daemon # auto-kill after 60s |
| 231 | ipfs shutdown # graceful shutdown via API |
| 232 | ``` |
| 233 | |
| 234 | Kill dangling daemons before re-running tests: `pkill -f "ipfs daemon"` |