|
6 | 6 |
|
7 | 7 | ## Build, Test, and Development Commands |
8 | 8 | - `docker compose up -d` boots the API, Postgres, Elasticsearch, Redis, and workers for local hacking. |
9 | | -- `docker compose run --rm api python manage.py test --keepdb -v3` runs the Django test suite quickly against the dev database. |
| 9 | +- `docker ps --format '{{.Names}}\t{{.Status}}'` should be your first check before running verification so you can reuse the existing service containers. |
| 10 | +- `docker exec oclapi2-api-1 python manage.py test --keepdb -v3` runs the Django test suite in the already-running API container and is the preferred default for routine verification. |
10 | 11 | - `docker exec -it oclapi2-api-1 pylint -j2 core` enforces lint rules. |
11 | 12 | - `docker compose -f docker-compose.yml -f docker-compose.ci.yml run --rm api bash coverage.sh` reports coverage and fails under the CI thresholds. |
12 | 13 | - `docker exec -it oclapi2-api-1 python manage.py search_index --populate -f --parallel` rebuilds Elasticsearch indexes after model or serializer changes. |
13 | 14 |
|
| 15 | +Always prefer `docker exec` into the existing `oclapi2-api-1` container over `docker compose run` for tests, lint, and management commands unless the user explicitly asks otherwise or the container is unavailable. |
| 16 | + |
14 | 17 | ## Coding Style & Naming Conventions |
15 | 18 | Use 4-space indentation, `snake_case` for functions/modules, and `PascalCase` for Django models and serializers. Keep imports sorted (stdlib, third-party, local) and lean on `pylint` to catch regressions. Favor explicit settings toggles by extending `core/toggles/` and document feature flags in docstrings above the flag definition. Apply KISS, DRY, and YAGNI: keep views/serializers simple, consolidate helpers per app, and skip speculative features. |
16 | 19 | Always comment code, in English only: add concise docstrings for functions, classes, and business rules, and favor descriptive names for variables and resolvers. For GraphQL schema fields, keep `description` attributes accurate and updated when behavior changes. Follow Django principles by centralizing shared logic, avoiding duplication across REST/GraphQL layers, and keeping resolvers thin by delegating to existing services or serializers. |
17 | 20 |
|
18 | 21 | ## Testing Guidelines |
19 | 22 | Target ≥93% coverage by pairing unit tests with integration cases. Name files `test_<feature>.py` and co-locate fixtures inside the app’s `tests/fixtures/`. Smoke Elasticsearch-dependent tests live in `core/integration_tests/` and should be guarded with `@skipUnless(settings.ES_ENABLED, ...)`. Use `python manage.py test app.tests --keepdb` for focused runs and include representative payloads in `core/samples/` when asserting serialization. |
| 23 | +For any code change, run targeted tests and pylint by default unless the user explicitly narrows verification. When using containers, prefer `docker exec oclapi2-api-1 ...` equivalents for both. |
20 | 24 |
|
21 | 25 | ## Commit & Pull Request Guidelines |
22 | | -Structure commit subjects using Conventional Commits (`feat(core): add repoType filter`) or issue references such as `OpenConceptLab/ocl_issues#2252 repo facets`. Keep one logical change per commit so release tooling can tag accurately. Follow GitFlow branches—start work on `feature/<issue-id>-slug` from `develop`, reserve `hotfix/*` for production fixes, and merge back through PRs only. Every PR must describe the motivation, list verification steps (`docker compose run --rm api python manage.py test…`), link the tracked issue, attach evidence when API responses change, and call out migrations, indexing, or env var impacts before requesting review. |
| 26 | +Structure commit subjects using Conventional Commits (`feat(core): add repoType filter`) or issue references such as `OpenConceptLab/ocl_issues#2252 repo facets`. Keep one logical change per commit so release tooling can tag accurately. Follow GitFlow branches—start work on `feature/<issue-id>-slug` from `develop`, reserve `hotfix/*` for production fixes, and merge back through PRs only. Every PR must describe the motivation, list verification steps (`docker exec oclapi2-api-1 python manage.py test…`, `docker exec oclapi2-api-1 pylint …`), link the tracked issue, attach evidence when API responses change, and call out migrations, indexing, or env var impacts before requesting review. |
23 | 27 |
|
24 | 28 | ## Security & Configuration Tips |
25 | 29 | Keep `vm.max_map_count=262144` set before starting Elasticsearch. For SSO, export `OIDC_SERVER_URL`, `OIDC_SERVER_INTERNAL_URL`, and `OIDC_REALM`; omitting them falls back to Django auth. Never commit secrets—use `.env` overrides or Docker compose profiles instead. |
0 commit comments