mirror of https://github.com/jxxghp/MoviePilot.git synced 2026-09-02 14:06:50 +08:00

Files

T

InfinityPacer 326b5cf3ad feat: 新增 Python 3.14t 自由线程镜像 (#6434 )

* fix(resource): select free-threaded extension ABI

* chore(deps): require moviepilot-rust 0.2.9

* perf: add free-threaded runtime comparison

* feat: add free-threaded runtime profile

* chore(deps): require moviepilot-rust 0.3.0

* test: isolate system endpoint import graph

* fix(docker): preserve runtime profile during recovery

* feat(runtime): expose active GIL state

* feat(plugin): log GIL fallback attribution

* test: refresh runtime observability dependency baseline

* fix(plugin): validate the active uv runtime profile

* test(runtime): expand free-threaded benchmark evidence

* docs(runtime): define v3t governance gates

* test(runtime): separate rust benchmark modes

* docs: sync free-threaded architecture baseline

* perf: add PostgreSQL driver comparison

* docs(runtime): record final free-threaded evidence

* fix(runtime): converge dual-profile dependency verification

* fix(runtime): scope Python 3.14 warning filter

* fix(runtime): match actual oss2 syntax warning

* docs(runtime): refresh free-threaded benchmark evidence

* test(architecture): refresh runtime dependency baseline

* ci: skip unused Trivy Java database

* build: exclude local verification artifacts

* docs(runtime): refresh PostgreSQL driver benchmarks

* docs(runtime): record plugin restore acceptance

* docs(runtime): record amd64 candidate acceptance

* ci: pin beta image publisher action

* test(architecture): merge runtime dependency baseline

* feat(runtime): expose Python GIL status

* docs(runtime): document Python runtime status fields

2026-08-24 17:48:14 +08:00

4.5 KiB

Raw Blame History

12 — Collaboration, Versioning, Build, and Release

Commit Conventions

This project uses Conventional Commits. The release workflow parses commit messages to categorize changelog entries. This is not stylistic — it is functional.

Format

<type>(<optional scope>): <description>

[optional body]

[optional footer]

Commit Types

Type	When to use
`feat`	A new feature visible to users
`fix`	A bug fix
`docs`	Documentation only changes
`chore`	Maintenance, dependency updates, tooling changes
`refactor`	Code restructuring without behavior change
`test`	Adding or modifying tests
`ci`	CI/CD pipeline changes
`perf`	Performance improvements

Examples

feat: support MiniMax audio provider
fix: sign media server image proxy URLs
docs: add MCP client configuration examples
chore: upgrade pydantic to 2.9.0
refactor: extract transfer path resolution into helper
test: add subscribe endpoint validation tests
ci: improve docker build cache

Rules

Local commits follow the active workflow, an approved plan, or current user authorization. Existing authorization does not require a second confirmation; push, PR, merge, and release remain separate delivery boundaries.
Keep the subject line under 72 characters.
Use the imperative mood in the subject line ("add", "fix", "remove", not "added", "fixed", "removed").
If a commit introduces a breaking change, append ! after the type and include BREAKING CHANGE: in the footer.

Branch Policy

When review or PR intent is already known, create or switch to a focused topic branch before editing. If that intent appears later, preserve valid work while moving it to a suitable branch.
The main development branch is the project default — check git branch rather than assuming it is main or master.
Feature work lives on dedicated branches and is merged via pull request.
Read-only investigation, throwaway diagnosis, and work explicitly kept local do not require a branch solely for process formality.
Do not force-push to shared branches.

Version Numbers

Do not casually change version numbers in version.py or related files.
Version changes are part of the release workflow and are only made when the task explicitly involves a release.
The FRONTEND_VERSION field in version.py controls which frontend release the CLI and Docker build will download. Only update it as part of a coordinated frontend release.

Docker Build and Release

The primary Docker image bundles the backend (Python app), frontend static files (from public/), and resource data.
Docker build and release are managed by CI. Do not manually trigger or alter the Docker release flow unless the task explicitly requires it.
If a Dockerfile change is needed, update Dockerfile and verify the build locally before submitting.

CI/CD

CI runs on every push and pull request. The pipeline typically includes:
- Dependency installation
- pytest test suite
- pylint static analysis
- Docker image build (on main branch or tags)
Do not merge code that fails CI unless there is an explicit, documented reason and user approval.

Pull Request Guidelines

Keep PRs focused on a single concern. Separate refactors, features, and bug fixes into distinct PRs when practical.
Include in the PR description:
- What changed and why
- How the change was validated
- Any known risks or compatibility impact
- Migration steps if config or database schema changed
Tag the PR with the appropriate label (bug, feature, docs, chore).

Dependency Release Process

When updating a dependency:

Decide the dependency layer: runtime packages go to [project].dependencies; test, coverage, lint, and explicit build tooling go to [dependency-groups].dev.
Run uv lock, commit the updated uv.lock, and verify it with uv lock --check.
Run uv sync --locked, the locked project consistency check, and the runtime dependency audit documented in 03-commands.md.
Run the full test suite: uv run --locked --no-sync pytest.

Local CLI Release

The moviepilot CLI is the local-mode entrypoint. Its update path is:

moviepilot update all     # updates backend + frontend + resources
moviepilot update backend # git pull + reinstall deps
moviepilot update frontend

Bootstrap installer changes live in scripts/bootstrap-local.sh. Only modify this script if the task explicitly involves the bootstrap flow.

Last Updated: 2026-08-19

4.5 KiB Raw Blame History