CI/CD

Every Python repository has a ci.yml workflow that runs on pull requests and on pushes to develop. Package repositories (entirius-py-*, entirius-django-*) also have publish.yml. The service has none: it is deployed, not published to PyPI (DevOps). A frontend’s ci.yml builds with its own package manager and runs the same secret scan; the jobs below are those of the Python repositories.

The workflow files to copy from are in entirius-django-pim.

ci.yml: lint, test, secret-scan

Trigger: push to develop, pull request to master or develop.

• Job lint: uv sync --frozen --all-extras (the environment exactly from the lock; the service has no extras and omits the flag), ruff check, ruff format --check, and the license header check (pre-commit run insert-license --all-files).
• Job test: pytest -x -q, after a green lint. A Django module that tests against PostgreSQL gives the job a postgres service and a DATABASE_URL.
• Job secret-scan: gitleaks with its default rules over the full history (fetch-depth: 0). Which gitleaks version each repository runs: Secret Scanning.

Required Checks

A pull request to develop or master is merged with lint, test and secret-scan green and with its branch up to date with the target. The other conditions of a pull request: Git Flow.

publish.yml: Build and Publish

Trigger: a published GitHub release. The workflow runs uv build and uv publish with PyPI trusted publishing: GitHub Actions exchanges a short-lived OIDC identity for a temporary upload token, so the repository stores no PyPI token. On the PyPI side the project names the repository, the workflow file publish.yml and the environment pypi as its trusted publisher.

How a release is cut: Releases.

Next

• Secret Scanning: the scan in pre-commit, on push and in CI
• Releases: the release that starts publish.yml
• Git Flow: branches and pull requests