|
| 1 | +# MongoDB Tools — Agent Instructions |
| 2 | + |
| 3 | +## Working Style |
| 4 | + |
| 5 | +We prefer that AI agents start by planning their work, documenting their plan as a Markdown file, |
| 6 | +and then iterating on that plan with the human operator. Don't just jump straight to coding in most |
| 7 | +cases. For small, well-scoped tasks (e.g., a one or two file change), it's fine to skip the planning |
| 8 | +step. |
| 9 | + |
| 10 | +Plans should be broken up into multiple steps. For larger projects, the plan should consider how to |
| 11 | +break the work up into multiple pull requests as well. We prefer PRs to be 200-400 lines. The |
| 12 | +exception would be a large rename or refactoring (like a type change), where the PR is very large in |
| 13 | +terms of lines but conceptually small. |
| 14 | + |
| 15 | +Save plans under `.ai-plans/$date/plan-name/plan.md`. |
| 16 | + |
| 17 | +## Requirements |
| 18 | + |
| 19 | +**The most important thing for these tools is that they must not corrupt or lose user data.** This |
| 20 | +is particularly important for `mongodump` and `mongorestore`. When we make changes to these tools, |
| 21 | +we should ensure that data is preserved via a dump and restore round trip. |
| 22 | + |
| 23 | +## Project Overview |
| 24 | + |
| 25 | +This repo contains the official MongoDB command-line tools: `bsondump`, `mongodump`, `mongorestore`, |
| 26 | +`mongoimport`, `mongoexport`, `mongostat`, `mongotop`, and `mongofiles`. |
| 27 | + |
| 28 | +Each tool lives in its own top-level directory (e.g., `/mongodump/`). Shared utilities are in |
| 29 | +`/common/`. |
| 30 | + |
| 31 | +## Build |
| 32 | + |
| 33 | +```bash |
| 34 | +go run build.go build # build all tools |
| 35 | +go run build.go build pkgs=<pkg> # build a specific tool |
| 36 | +``` |
| 37 | + |
| 38 | +Binaries are written to `./bin/`. |
| 39 | + |
| 40 | +## Tests |
| 41 | + |
| 42 | +Tests use environment variables to control which test types run. |
| 43 | + |
| 44 | +```bash |
| 45 | +go run build.go test:unit # unit tests (no mongod required) |
| 46 | +go run build.go test:integration # requires mongod on localhost:33333 |
| 47 | +go run build.go test:sharded-integration # requires mongos (sharded cluster) |
| 48 | +``` |
| 49 | + |
| 50 | +Optional flags for `test:integration`: `ssl=true`, `auth=true`, `topology=replset`, `race=true`. |
| 51 | + |
| 52 | +All tests use `testtype.SkipUnlessTestType(t, testtype.XxxTestType)` at the top to gate on the |
| 53 | +relevant env var. When writing new tests, match the existing pattern. |
| 54 | + |
| 55 | +Integration tests default to connecting to `localhost:33333`. Override with |
| 56 | +`TOOLS_TESTING_MONGOD=<uri>`. |
| 57 | + |
| 58 | +Before running integration or sharded integration tests, you must have a MongoDB server or cluster |
| 59 | +running and accessible. For basic integration tests, start a standalone `mongod` on port 33333. For |
| 60 | +sharded integration tests, start a `mongos` fronting a sharded cluster. These servers are not |
| 61 | +started automatically by the test runner. |
| 62 | + |
| 63 | +Use `mlaunch` (from the `mtools` Python package) to manage clusters during development: |
| 64 | + |
| 65 | +```bash |
| 66 | +mlaunch init --single --port 33333 # standalone mongod for integration tests |
| 67 | +mlaunch init --sharded 1 --port 33333 # sharded cluster for sharded integration tests |
| 68 | +mlaunch stop # stop all launched processes |
| 69 | +mlaunch start # restart previously initialized cluster |
| 70 | +``` |
| 71 | + |
| 72 | +## Static Analysis |
| 73 | + |
| 74 | +Our static analysis tools are managed locally by `mise`. Always modify the `mise.toml` file to add |
| 75 | +or update tools. But we _also_ manage these in CI via code in `buildscript`, so this must be updated |
| 76 | +in sync with the `mise.toml` file. |
| 77 | + |
| 78 | +```bash |
| 79 | +go run build.go sa:lint # runs precious (golangci-lint, gosec, goimports, golines) |
| 80 | +go run build.go sa:modtidy # go mod tidy |
| 81 | +``` |
| 82 | + |
| 83 | +## Code Conventions |
| 84 | + |
| 85 | +- Use `any` instead of `interface{}`. |
| 86 | +- Avoid comments that describe _what_ code does; only comment on _why_ when the reason isn't |
| 87 | + obvious. |
| 88 | +- Break large functions into smaller named functions rather than adding explanatory comments. |
| 89 | +- Write test assertion messages that describe what is being tested. |
| 90 | +- New tests should use `testify` (`github.com/stretchr/testify/require` and `assert`). The codebase |
| 91 | + is actively migrating away from GoConvey — do not add new GoConvey tests. |
| 92 | + |
| 93 | +## Architecture |
| 94 | + |
| 95 | +``` |
| 96 | +/common/ shared utilities (auth, db, bsonutil, options, testutil, testtype, …) |
| 97 | +/<tool>/ tool implementation |
| 98 | +/<tool>/main/ CLI entry point (main package) |
| 99 | +/<tool>/options.go CLI flag definitions |
| 100 | +/<tool>/*_test.go tests co-located with source |
| 101 | +``` |
| 102 | + |
| 103 | +Shared connection and session management lives in `common/db/`. CLI options are parsed via |
| 104 | +`common/options/` using `github.com/urfave/cli/v2`. |
| 105 | + |
| 106 | +## CI |
| 107 | + |
| 108 | +CI runs on Evergreen (config: `common.yml`). Do not edit `common.yml` by hand for test topology |
| 109 | +changes — consult the existing pattern for `integration-X.Y` and `integration-X.Y-sharded` task |
| 110 | +variants. |
| 111 | + |
| 112 | +## Minimal Change Principle |
| 113 | + |
| 114 | +Make minimal, incremental changes. Do not refactor surrounding code when fixing a bug or adding a |
| 115 | +feature. Do not add error handling for scenarios that cannot occur. |
0 commit comments