Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/test.yml
Original file line number Diff line number Diff line change
Expand Up @@ -107,7 +107,7 @@ jobs:
run: echo "PYTHONPATH=${GITHUB_WORKSPACE}/release_notes_generator/release_notes_generator" >> $GITHUB_ENV

- name: Check code coverage with Pytest
run: pytest --cov=. -v tests/ --cov-fail-under=80
run: pytest --cov=. -v tests/unit --cov-fail-under=80

mypy-check:
runs-on: ubuntu-latest
Expand Down
115 changes: 103 additions & 12 deletions .specify/constitution.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
Sync Impact Report
Version change: 1.0.0 -> 1.0.1
Modified sections: Governance & Ownership (maintainers list)
Added sections: None
Version change: 1.3.0 -> 1.4.0
Modified sections: Principle 13 expanded to include fix/, docs/, chore/; Quality Gates branch naming; Compliance Review
Added sections: Allowed prefix list & category descriptions; CI workflow enforcement `.github/workflows/branch-prefix-check.yml`
Removed sections: None
Change type: PATCH (metadata clarification, no principle change)
Templates requiring updates: None (no template impact)
Change type: MINOR (expanded enforceable governance rule)
Templates requiring updates: plan-template.md (✅), tasks-template.md (✅), spec-template.md (✅), DEVELOPER.md (✅), CONTRIBUTING.md (✅), branch-prefix-check.yml (✅)
Deferred TODOs: None
-->

# Release Notes Scrapper Action Constitution
Expand Down Expand Up @@ -65,11 +66,23 @@ manage version tagging; it consumes existing tags.
7. `ReleaseNotesBuilder` iterates chapters → collects matching records → applies row format templates / duplicity markers.
8. Final Markdown string emitted; composite action sets `release-notes` output.

### Boundary Rules
### Boundary Rules (Refined)
- Action inputs boundary: all configurable behavior must pass via declared inputs (no hidden runtime switches).
- GitHub API boundary: all repository data access encapsulated within miner and rate limiter logic.
- Formatting boundary: only row format templates and chapters influence visible line structure; business logic must not
directly embed presentation markup elsewhere.
- Error boundary: modules MUST NOT leak raw exceptions across boundaries; they must convert failures into logged events
and structured return values (see Principle 9). Internal exceptions MAY be raised and caught within the same module.
- Utility boundary: functions in `utils/` MUST be demonstrably used by at least one importing module or removed (see Principle 8 & 10).

### Module Boundary Follow-Up
A scheduled audit SHALL verify:
- `utils/` contains only actively referenced functions (dead code removal list to be created).
- `generator.py` remains orchestration-only (no direct formatting or low-level API calls beyond miner invocation).
- `builder/` never performs mining; strictly transforms records to Markdown.
- `record/factory` isolates construction logic; future refactors MAY extract validation into a separate `validators/` module.
- Logging configuration centralization: confirm no duplicate ad-hoc log setup outside `main.py`.
Outcome: Produce a follow-up task list referencing each violation if found; merge only with accompanying unit tests.

## 3. Data & Integrations

Expand Down Expand Up @@ -119,13 +132,39 @@ manage version tagging; it consumes existing tags.
## 5. Quality & Testing

### Test Types
- Unit tests (expected for pure utility and formatting functions).
- Unit tests for pure utility, transformation, formatting, and record construction functions.
- Integration tests (e.g. `integration_test.py`) covering end-to-end generation using mocked or controlled data.
- No explicit contract tests yet; future addition may define record/chapter contract snapshots.
- Future: contract/snapshot tests MAY be introduced for chapter output stability (not mandatory yet).

### Test Directory Structure (New)
```
tests/
unit/ # All Python unit tests (test_<module>.py) - REQUIRED location
integration/ # Future integration tests (current single file may migrate here)
fixtures/ # Shared static test data & factories (optional)
helpers/ # Helper utilities used only by tests (must be imported by tests/*)
release_notes/ # Domain-specific sample data (review for possible move under fixtures/)
utils/ # Test-only utility functions (rename to helpers/ or remove if redundant)
```
Rules:
- All unit tests MUST reside under `tests/unit/` (root-level `test_*.py` files SHALL be relocated).
- Naming: `test_<target>.py`; multiple related small targets MAY share one file if cohesive.
- Test style: uses ONLY `pytest` (no unittest classes). Prefer functions + fixtures.
- Fixtures: define shared objects in `tests/conftest.py` or per-file fixtures; keep scope minimal.
- Parametrization: use `@pytest.mark.parametrize` for input matrix instead of loops.
- Coverage: new logic MUST raise overall coverage or keep it steady; dropping coverage requires explicit justification.
- NEW: Unit test file path MUST mirror source relative package path (Principle 12). For source file `release_notes_generator/utils/constants.py`, the test lives at `tests/unit/release_notes_generator/utils/test_constants.py`.
- Branch Naming: Feature / fix / docs / chore PRs MUST originate from correctly prefixed branch (Principle 13); CI may validate.

### Organization & Integration
- Integration tests MUST import public interfaces only (`main`, `ReleaseNotesGenerator`) not internal private helpers.
- Unit tests MUST avoid real network calls; use mocking or local sample data.
- Cross-test independence: tests MUST NOT rely on execution order; no shared mutation outside fixture scope.
- Relocation of existing root-level unit tests into `tests/unit/` SHALL be part of first compliance PR post-amendment.

### Coverage
- `pytest-cov` integrated; HTML coverage artifacts seen in `htmlcov/`. Target: maintain or improve existing coverage
(implicit baseline > minimal demonstration). New core logic MUST include tests before implementation (Test‑First Principle).
- `pytest-cov` integrated; HTML coverage artifacts under `htmlcov/`. Baseline maintained or improved. New core logic MUST
include tests before implementation (Test‑First Principle).

### Static Analysis & Review
- `pylint`, `mypy` required to pass (configuration present).
Expand All @@ -135,7 +174,9 @@ manage version tagging; it consumes existing tags.
### Quality Gates (Minimum Acceptance)
- Tests: ALL must pass.
- Lint + type: zero blocking errors.
- No unused functions/methods (see Principle 10) — introduce usage or delete in same PR.
- Backward compatibility: no silent change to input names or placeholder semantics without version bump & documentation update.
- Branch naming compliance (Principle 13) — allowed prefixes: feature/, fix/, docs/, chore/; rename if violated.

## 6. Constraints & Compatibility

Expand Down Expand Up @@ -169,6 +210,7 @@ manage version tagging; it consumes existing tags.
- Hierarchy expansion could incur additional API calls increasing latency.
- Duplicate detection edge cases may confuse users if same issue intentionally spans categories.
- CodeRabbit integration features may parse unintended summary content (format variance risk).
- Dead code accumulation in `utils/` may reduce clarity if Principle 10 not enforced promptly.

### Assumptions
- Repository uses semantic version tags (prefixed optionally by `v`).
Expand Down Expand Up @@ -200,6 +242,7 @@ manage version tagging; it consumes existing tags.
### Compliance Review
- PR template or automated check SHOULD reference Constitution principles (especially Test‑First & Stability) before merge.
- Violations require explicit justification section in PR description.
- Review checklist MUST confirm Principle 13 prefix correctness and scope alignment.

### Release Management
- Tagging strategy external; this action consumes tags. Recommend semantic versioning for repository releases.
Expand Down Expand Up @@ -236,7 +279,7 @@ Ensure Constitution Check section in `plan.md` passes before advancing to detail

## Change Log / Versioning
- Project releases follow Git tags; this constitution uses semantic versioning independent of code releases.
- Current Constitution Version: 1.0.1 (initial ratification).
- Current Constitution Version: 1.4.0 (amended with new principles & test structure).
- Future amendments tracked via Sync Impact Report at top of this file.

## Core Principles
Expand Down Expand Up @@ -277,5 +320,53 @@ Mining MUST use rate limiter abstraction; avoid redundant API calls (e.g. re-fet
MUST short-circuit when disabled. Performance considerations addressed before accepting features that multiply API calls.
Rationale: Preserves quota & improves speed on large repositories.

### Principle 8: Lean Python Design
Prefer simple functions and modules over unnecessary classes. A class MUST only be introduced when stateful behavior or
polymorphism is required. Utility modules SHOULD expose pure functions. Avoid deep inheritance; favor composition.
Rationale: Reduces complexity and improves readability & testability.

### Principle 9: Localized Error Handling & Non-Exceptional Flow
Modules MUST catch internal exceptions and convert them into structured return values plus logged messages. Cross-module
exception propagation (raising raw exceptions across boundaries) is prohibited except for truly unrecoverable setup
failures at the entry point (`main`). Return either a valid result or a clearly logged empty/partial result.
Rationale: Ensures predictable action behavior and prevents silent termination in CI pipelines.

### Principle 10: Dead Code Prohibition
No unused methods/functions SHALL remain in the codebase (properties or inherited abstract/interface methods excepted).
Utility files MUST contain only actively invoked functions. Removal of unused code MUST occur in the same PR that
introduces its obsolescence.
Rationale: Prevents confusion, reduces maintenance overhead, and keeps coverage meaningful.

### Principle 11: Focused & Informative Comments
Comments MUST explain non-obvious logic, constraints, or reasoning succinctly. Prohibited: narrative, outdated, or
speculative comments. Allowed: brief context before complex loops, rationale for workaround, links to issue references.
Comments SHOULD be maintained or updated alongside code changes; stale comments MUST be removed.
Rationale: Enhances clarity without adding noise.

### Principle 12: Test Path Mirroring
Each unit test file MUST reside under `tests/unit/` mirroring the source package path and file name: `tests/unit/<source_root_relative_path>/test_<original_file_name>.py`.
Mandatory Rules:
- One test file per source file unless tightly coupled logic demands grouping (justify in PR).
- Legacy non-mirrored category folders are deprecated; migrate incrementally without reducing coverage.
- New or refactored modules require mirrored test path in same PR.
Rationale: Ensures predictable test discovery, simplifies navigation between code and tests, and supports scalable refactors.

### Principle 13: Branch Naming Consistency
All new branches for work MUST start with one of the approved prefixes followed by a concise kebab-case descriptor (optional numeric ID).
Approved prefixes:
- `feature/` – new features & enhancements
- `fix/` – bug fixes / defect resolutions
- `docs/` – documentation-only updates
- `chore/` – maintenance, dependency bumps, CI, non-behavioral refactors
Examples:
`feature/add-hierarchy-support`, `fix/567-handle-empty-chapters`, `docs/improve-readme-start`, `chore/upgrade-semver-lib`
Rules:
- Prefix REQUIRED and MUST be in approved set; rename non-compliant branches prior to PR.
- Descriptor: lowercase kebab-case; hyphen separators; no spaces/underscores/trailing slash.
- Optional numeric ID may precede description (`fix/987-null-title`).
- Category alignment: branch prefix MUST match primary scope of PR contents.
- Avoid vague descriptors (`update`, `changes`). Prefer action or subject (`improve-logging`, `remove-dead-code`).
Rationale: Standardizes history, enables automated governance checks, clarifies intent for reviewers & tooling.

## Governance Metadata
**Version**: 1.0.1 | **Ratified**: 2025-10-12 | **Last Amended**: 2025-10-12
**Version**: 1.4.0 | **Ratified**: 2025-10-12 | **Last Amended**: 2025-10-14
Loading
Loading