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
12 changes: 6 additions & 6 deletions AUDIT.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,13 @@ This document outlines the results of an audit of the repository against modern
### 1. Central Configuration and Legacy Files
- **`pyproject.toml`**: **[PASS]** A `pyproject.toml` file exists at the root, which is mandatory for modern packaging.
- **Legacy Files**: **[PASS]** `setup.py`, `setup.cfg`, and `requirements.txt` are not used for core metadata or dependency management. All configuration is correctly centralized in `pyproject.toml`.
- **`poetry.lock`**: **[FAIL]** A `poetry.lock` file is present. This is a legacy artifact from a previous Poetry-based setup and is inconsistent with the current `setuptools` build backend. It must be removed.
- **`poetry.lock`**: **[PASS]** The legacy `poetry.lock` file has been successfully removed.
- **`MANIFEST.in`**: **[PASS]** This file is not present.

### 2. Build System (PEP 517 & PEP 518)
- **`[build-system]` Table**: **[PASS]** This table is present in `pyproject.toml`.
- **`build-backend`**: **[PASS]** A modern, PEP 517-compliant backend, `setuptools.build_meta`, is specified.
- **`requires`**: **[PASS]** The build dependencies are correctly listed as `["setuptools>=61.0"]`.
- **`build-backend`**: **[PASS]** A modern, PEP 517-compliant backend, `hatchling.build`, is specified.
- **`requires`**: **[PASS]** The build dependencies are correctly listed as `["hatchling"]`.

### 3. Project Metadata (PEP 621)
- **`[project]` Table**: **[PASS]** This table is present in `pyproject.toml`.
Expand All @@ -25,7 +25,7 @@ This document outlines the results of an audit of the repository against modern

### 4. Dependencies (PEP 508)
- **`dependencies`**: **[PASS]** Runtime dependencies are correctly specified as an empty array.
- **`optional-dependencies`**: **[PASS]** Extras for development are correctly defined in `[project.optional-dependencies]`.
- **`optional-dependencies`**: **[PASS]** Extras for development are correctly defined using PEP 735 `[dependency-groups]`.

### 5. Project Structure and Layout
- **Layout**: **[PASS]** The project uses the recommended `src` layout (`src/my_python_project/`).
Expand All @@ -37,11 +37,11 @@ This document outlines the results of an audit of the repository against modern
- **Configuration**: **[PASS]** The testing configuration is centralized in `[tool.pytest.ini_options]` within `pyproject.toml`.

## Conclusion
The project is already in excellent condition and fully compliant with modern Python packaging standards. The only required action is the removal of the legacy `poetry.lock` file. No further refactoring is necessary.
The project is already in excellent condition and fully compliant with modern Python packaging standards. No further refactoring is necessary.

## Phase 3: Conformance Verification

- **[X] Standards Compliance and Configuration**: `pyproject.toml` is the primary source of truth, the `[build-system]` is correctly configured, and all legacy configuration files have been removed.
- **[X] Structure and Discoverability**: The project utilizes the `src` layout, and the build backend is correctly configured to discover packages.
- **[X] Build Integrity**: The package builds successfully into both sdist and wheel formats using `python3 -m build`. The generated artifacts correctly include the source code, `LICENSE`, and `README` files.
- **[X] Build Integrity**: The package builds successfully into both sdist and wheel formats using `uv build`. The generated artifacts correctly include the source code, `LICENSE`, and `README` files.
- **[X] Installation and Testing**: The package can be installed in a fresh virtual environment and in editable mode. The test suite runs successfully against the installed package.
10 changes: 5 additions & 5 deletions CI_CD_STRATEGY.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,20 +4,20 @@ This document outlines the CI/CD architecture for this project, including the Do

## CI/CD Architecture

The CI/CD pipeline is built using GitHub Actions and is divided into two workflows: `ci.yml` and `docker.yml`.
The CI/CD pipeline is built using GitHub Actions and is divided into two workflows: `ci-cd.yml` and `docker.yml`.

- **`ci.yml`**: This workflow is triggered on `push` and `pull_request` events to the `main` and `develop` branches. It consists of two jobs:
- **`ci-cd.yml`**: This workflow is triggered on `push` and `pull_request` events to the `main` and `develop` branches. It consists of two jobs:
1. **`lint`**: This job runs the `pre-commit` suite to ensure all code adheres to the defined quality and style standards.
2. **`test`**: This job runs the `pytest` suite across a matrix of Python versions (3.10, 3.11, and 3.12) to ensure the code is working as expected. It depends on the `lint` job, so it will only run if the linting passes.
2. **`test`**: This job runs the `pytest` suite across a matrix of Python versions (Python 3.14 and 3.14t (free-threading)) to ensure the code is working as expected. It depends on the `lint` job, so it will only run if the linting passes.

- **`docker.yml`**: This workflow is triggered on `push` events to the `main` and `develop` branches. It builds, scans, and pushes a Docker image to the GitHub Container Registry.

## Docker Strategy

The `Dockerfile` is a multi-stage build to create a lean and secure production image.

- **Stage 1 (Builder)**: This stage installs Poetry, exports the project dependencies to a `requirements.txt` file, and installs them. It also installs the application itself.
- **Stage 2 (Runtime)**: This stage uses a slim Python base image, creates a non-root user, and copies the installed dependencies and application from the builder stage. This results in a smaller and more secure final image.
- **Stage 1 (Builder)**: This stage installs `uv`, uses it to sync project dependencies via `uv sync`, and builds the application into a wheel (`uv build`), leveraging BuildKit caching.
- **Stage 2 (Runtime)**: This stage uses a slim Python 3.14 base image, creates a non-root user, and installs the wheel using `uv pip` from the builder stage. This results in a smaller and more secure final image.

## Security Measures

Expand Down