YoungLion v0.1 uses two workflows with deliberately separate responsibilities.
Runs on pushes to main, pull requests, and manual dispatches. It validates:
- native C++ builds on Ubuntu x86_64/ARM64, Windows, macOS Intel and Apple Silicon;
- the oldest and newest supported CPython lines used by the fast source matrix;
- strict compiler diagnostics (
-Werror//WX); - Python syntax, smoke tests, pytest, and public stub coverage;
- clean PEP 517 source installs inside Debian, Arch Linux, Fedora, Rocky Linux 9, openSUSE Tumbleweed, and Alpine containers;
- an opt-in Windows ARM64 preview job when manually dispatched.
The distribution-container jobs intentionally install with pip install . in a
fresh virtual environment. They must not call setup.py with the distro's
preinstalled setuptools, because pyproject.toml is the authoritative source of
build requirements.
This workflow is manual (workflow_dispatch) and also runs for version tags.
Matching tags publish automatically; manual runs publish only when
publish_release=true. Its first job is a release preflight gate that verifies:
- a tag, when present, exactly matches
v<project.version>; - the obsolete pre-v0.1 automatic release workflow is absent;
- strict native compilation succeeds;
- smoke tests, pytest, syntax checks, stub coverage and semantic typing pass;
- runtime/project versions agree and versioned release notes exist;
- publication is requested from the default branch or matching version tag.
Only after preflight succeeds are the sdist and wheel matrices allowed to start.
The final job downloads the component artifacts and produces one
YoungLion-<version>-release-bundle artifact.
The native extension uses C++17 std::filesystem. YoungLion therefore sets a
macOS deployment floor that is high enough for the libc++ filesystem APIs:
- Intel build fallback: macOS 10.15;
- Apple Silicon native fallback: macOS 11;
- cibuildwheel configuration:
MACOSX_DEPLOYMENT_TARGET = "10.15", which the wheel builder raises when the selected architecture requires a newer floor.
Do not remove this setting merely to produce an older-looking wheel tag; the binary must never claim compatibility with an OS whose C++ runtime cannot load features used by the extension.
After stable builds and bundle validation, publication stages a draft GitHub
Release, uploads only unpublished stable files to PyPI with the organization
PYPI_API_TOKEN, verifies every registry SHA-256 digest, then publishes the
GitHub Release. Existing assets must have identical bytes; tags are never moved.
See Publishing and recovery. Artifact-only manual runs remain
available with publish_release=false.