The README prerequisites were both stale, and the docs restated the Go version in three places. ## Prerequisites: name the source, do not restate the version | README said | Reality | |---|---| | `Go 1.24.x` | `go 1.26` in [go.mod](https://github.com/modelcontextprotocol/registry/blob/main/go.mod) | | `golangci-lint v2.4.0` | `v2.11.4` pinned in [ci.yml:30](https://github.com/modelcontextprotocol/registry/blob/main/.github/workflows/ci.yml#L30) | Rather than swap in fresher numbers — which only resets the clock on the same drift — this **removes the numbers** and names the authoritative file: ``` - **Go** - version per the `go` directive in go.mod; the Go toolchain fetches it for you - **golangci-lint** - version per the `golangci-lint-action` pin in ci.yml, so local lint matches CI ``` The Go version was stated in **three** places, which is exactly why all three drifted together. All three now point at a single source, so the prerequisites list cannot go stale. Two notes on why the numbers earn so little in prose: - **Go corrects itself.** `go.mod` has no `toolchain` directive, so under the default `GOTOOLCHAIN=auto` the toolchain downloads the required version automatically. A contributor on an older Go gets an upgrade, not a failure — it only hard-errors under `GOTOOLCHAIN=local`. (An earlier version of this description said such a contributor "cannot build"; that was too strong.) - **golangci-lint does not.** Version skew here genuinely changes what you see: running CI's config under a newer golangci-lint (2.12.2) surfaces 23 `goconst` findings in `cmd/publisher/commands/validate_test.go` that CI's pinned 2.11.4 does not report. That is why the README now points at the pin rather than a number someone has to keep in sync. ## `make check` does more than documented Documented in three files as "lint, unit tests and integration tests". Actually [`check: dev-down lint validate test-all`](https://github.com/modelcontextprotocol/registry/blob/main/Makefile#L85) — it also runs schema validation and **stops your running `dev-compose` environment**. Worth knowing before running it mid-session. The Makefile's own `##` help string already said this correctly; only the prose was stale. ## Other verified corrections - **README project structure** omitted `cmd/registry/` — the server entry point and ko/goreleaser build target — and `internal/importer/`. - **`tests/integration/README.md`** said the suite launches **MongoDB**. It launches PostgreSQL (`postgres-integration-test`), as the same file admits nine lines later. It also cited `/v0/servers/{server_id}`, a path removed a while ago; the test actually calls `GET /v0/servers` and `GET /v0/servers/{serverName}/versions/latest` ([main.go:210,255](https://github.com/modelcontextprotocol/registry/blob/main/tests/integration/main.go#L210)). - **`scripts/mirror_data/README.md`** pointed at `internal/database/migrations/008_separate_official_metadata.sql`, which does not exist — that migration is `009_`, while `008_` is `clean_invalid_data.sql`. (Migration 008's own header still calls itself "007a", which is how the numbering slipped.) Also swapped two "edit line NN" pointers for identifier names, since both had already drifted (`maxMigration` is at :30 not :24; the connection string at :23 not :17), and corrected the fetch URL from `/v0.1/servers` to the `/v0/servers` the script actually requests. - **`.env.example`** was missing `MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION`, even though the config reads it ([config.go:18](https://github.com/modelcontextprotocol/registry/blob/main/internal/config/config.go#L18)) and README:50 tells contributors to set it while pointing at `.env.example` as *the* reference. - **`docker-compose.yml`** set `MCP_REGISTRY_ENVIRONMENT`, which nothing reads — no `ENVIRONMENT` env tag in `internal/config`, and no other occurrence in the repo. Removed. (The Pulumi-side `mcp-registry:environment` key is a separate, real thing and is untouched.) - **Deleted `CHANGES.md`** — 0 bytes, untouched since the squashed history base, zero references anywhere. ## Verification `docker compose config` validates. `grep` for `Go 1.x` / `golangci-lint vX` across all `.md`/`.mdx` now returns nothing outside `complete.md` (which #1522 deletes). Both `../../README.md#pre-requisites` links resolve and the anchor matches the real `#### Pre-requisites` heading. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
1.5 KiB
1.5 KiB
Integration Test
This directory contains an end-to-end test for publishing to the registry.
What the Test Covers
- Publisher Tool: Tests the
publisherCLI that publishes metadata to the registry - Registry API: Validates that
/v0/publish,GET /v0/servers, andGET /v0/servers/{serverName}/versions/latestwork correctly - Example Validation: Ensures all example JSON in
docs/reference/server-json/generic-server-json.mdis valid and can be published - Data Consistency: Verifies published data matches what's retrieved from the registry
Test Flow
- Build: Build
publisherandregistry - Start Services: Launch registry and PostgreSQL using Docker Compose with test configuration
- Publish Examples: Extract JSON examples from documentation and run
publisherto publish each one - Validate Responses: GET each published server from the registry and compare it to the example JSON
- Cleanup: Stop Docker containers and remove temporary files
How to Run
Prerequisites
- Docker and Docker Compose
- Go — see the prerequisites in the root README for the required version
- Make sure you're in the repository root directory
Run the Tests
./tests/integration/run.sh
Note: Integration tests use isolated container names (registry-integration-test, postgres-integration-test) to prevent conflicts with development containers from make dev-compose.