{"owner":"apolloconfig","repo":"apollo","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"files":{"AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n- Multi-module Maven repo with root `pom.xml` and service modules like `apollo-configservice`, `apollo-adminservice`, and `apollo-portal`, shared libs in `apollo-common`, and packaging in `apollo-assembly`.\n- `apollo-biz` is a shared business-logic module used by services like config/admin (not a standalone service).\n- Build and release tooling lives in `scripts/` (e.g., `scripts/build.sh`) and `apollo-buildtools/` (code style configs).\n- Database and schema assets are under `scripts/sql` and module `src/main/resources` folders.\n- Tests follow standard Maven layout: `*/src/test/java` and `*/src/test/resources` inside each module.\n- Documentation is in `docs/`.\n\n## Build, Test, and Development Commands\n- `./mvnw -DskipTests package` builds all modules.\n- `./mvnw test` runs the full test suite via Surefire (may log warnings if local meta/admin services are not running).\n- `./mvnw -pl apollo-configservice -am test` runs tests for a specific module and its dependencies.\n- `./mvnw spotless:apply` formats code and must be run before opening a PR.\n- `./scripts/build.sh` generates distributable packages (used for deployment workflows).\n\n## Coding Style & Naming Conventions\n- Follow Google Java Style Guide; 2-space indentation and standard Java conventions apply.\n- Use the IDE configs in `apollo-buildtools/style/` (IntelliJ/Eclipse).\n- New Java classes should include a short Javadoc describing the class purpose.\n- Use standard Java naming: packages `lower.case`, classes `UpperCamelCase`, tests `*Test`.\n\n## OpenAPI Contract Workflow (apollo-portal)\n- Treat OpenAPI as contract-first: update spec in `apolloconfig/apollo-openapi` before (or together with) portal implementation changes.\n- `apollo-portal/pom.xml` uses `apollo.openapi.spec.url` + `openapi-generator-maven-plugin`; generated sources under `target/generated-sources/openapi/src/main/java` are added to compile path via `build-helper-maven-plugin`.\n- For new/changed OpenAPI endpoints, prefer implementing generated `*ManagementApi` interfaces and generated models; avoid introducing hand-written DTO/controller contracts that bypass the spec pipeline.\n- In PR review, verify contract alignment explicitly: endpoint path, request/response model, and permissions in `apollo` should match the spec in `apollo-openapi`.\n\n## Testing Guidelines\n- JUnit 5 is the default, with Vintage enabled for legacy JUnit 4 tests.\n- Put new tests under the module’s `src/test/java` with `*Test` suffix.\n- Add unit tests for new features or important bug fixes.\n\n## Commit & Pull Request Guidelines\n- Use Conventional Commits format (e.g., `feat:`, `fix:`).\n- If a commit fixes an issue, append `Fixes #123` in the commit message.\n- Commit only on feature branches; never commit directly to `master` or `main`.\n- `CHANGES.md` entries must use a PR URL in Markdown link format; if the PR URL is not available yet, open the PR first, then add/update `CHANGES.md` in a follow-up commit.\n- Rebase onto `master` and squash feature work into a single commit before merge.\n- When merging a PR on GitHub: if it has a single commit, use rebase and merge; if it has multiple commits, use squash and merge.\n- Non-trivial contributions require signing the CLA.\n- Open a feature branch for your change and submit a PR using `.github/PULL_REQUEST_TEMPLATE.md`.\n- PRs should include a clear description, tests run, and any relevant screenshots/logs; use GitHub issues for tracking.\n- The PR checklist expects `mvn clean test`, `mvn spotless:apply`, and an update to `CHANGES.md`.\n- For upstream contributions, open PRs against `apolloconfig/apollo` and fill the template with real content (not the raw template text).\n\n## Security & Configuration Notes\n- Apollo supports H2 in-memory for local development and MySQL for production; prefer H2 locally unless you need a real database.\n- Review `scripts/sql` and environment config when using MySQL.\n- Do not commit secrets or environment-specific credentials; use local overrides instead.\n- Follow `SECURITY.md` for vulnerability reporting.\n"}}