47b4c5fbfb
CI / push-validation (push) Successful in 10s
CI / helm (push) Successful in 28s
CI / build (push) Successful in 29s
CI / typecheck (push) Successful in 53s
CI / lint (push) Successful in 3m44s
CI / quality (push) Successful in 3m58s
CI / security (push) Successful in 4m12s
CI / e2e_tests (push) Successful in 4m49s
CI / integration_tests (push) Successful in 6m47s
CI / unit_tests (push) Successful in 8m3s
CI / docker (push) Successful in 1m31s
CI / coverage (push) Successful in 10m51s
CI / status-check (push) Successful in 1s
CI / benchmark-publish (push) Has been cancelled
CI / benchmark-regression (push) Has been cancelled
SKILL.md (1,878 → 2,099 lines, 23 → 25 decision trees): New 'Is my work done?' tree — comprehensive Definition of Done checklist synthesising all requirements across implementation, three-level testing (unit/integration/benchmarks), coverage ≥ 97%, five CI quality checks, commit anatomy (atomic, body, footer), documentation (changelog, docstrings, CONTRIBUTORS.md), PR fields (description, dep direction, Epic scope, milestone, Type label), CI checks, and issue state transitions. New 'What design pattern should I use?' tree — all 24 patterns from CONTRIBUTING.md categorised across Creational (Factory, Abstract Factory, Builder, Prototype, Singleton, Object Pool, DI), Structural (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Module), Behavioral (Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor, Null Object), and Architectural (Repository, Unit of Work, Service Layer, MVC, CQRS, Event Sourcing, Specification). Every pattern includes a when-to-use description and a CleverAgents-specific example. Expand 'Am I about to write code?' — link to new patterns tree. Expand 'Am I writing tests?' — add And/But/Outline Gherkin keywords with examples, add Scenario Outline explanation, add naming good/bad examples with anti-pattern list, expand integration test guidance with what good integration tests exercise (CLI, DB, filesystem, service layer), expand Hypothesis section with 6 specific use cases and recommended strategies to build. Expand 'Am I about to commit?' — improve commit body guidance with a worked example showing what to write (context, why this approach, risks, caveats). Expand 'Am I triaging?' — add Epic/Legendary triage rules (no point estimates, no milestone assignment, sign-off labels required for closure). Add two branches to master decision tree for new trees. Reference files: references/testing/README.md (187 → 296 lines): - Add Gherkin Quality Guidelines section: Given/When/Then semantics table, Scenario Outline explanation with example, naming rules with good/bad table, common anti-patterns (implementation details, multiple behaviors, missing Then) - Add Property-Based Testing (Hypothesis) section: when-to-use table with 6 specific CleverAgents use cases, recommended strategies to build, integration with Behave step definitions with worked example references/langchain-langgraph/README.md (307 → 375 lines): - Add RxPY Reactive Streams section: Subject vs BehaviorSubject vs ReplaySubject decision table with when-to-use and code examples, key operators table with use cases and code examples, backpressure management patterns (debounce vs throttle_first with examples), and clear list of what RxPY is NOT for references/toolchain/README.md (271 → 272 lines): - Add Hypothesis to tool table (property-based testing, nox -s unit_tests) references/ci-cd/README.md (124 → 131 lines): - Fix project-specific version number in release example (v3.6.0 → generic v<MAJOR>.<MINOR>.<PATCH>) - Add release failure recovery procedure (verify secrets → build locally → delete tag → fix → re-tag) ISSUES CLOSED: #0
CI/CD Pipeline — CleverAgents Project
⚠️ Rules here override
cleverthis-guidelines. Apply these exactly.
Workflow Files
All pipeline definitions live in .forgejo/workflows/.
| Workflow | Trigger | Purpose |
|---|---|---|
ci.yml |
Push to master/develop; PRs to master/develop* |
Full CI: lint, typecheck, security, quality, tests, coverage, benchmarks, build, Docker |
nightly-quality.yml |
Daily at midnight UTC; manual dispatch | Extended quality sweep with complexity and maintainability analysis |
release.yml |
Push of v* tags (e.g. v3.6.0) |
Build wheel, build and push Docker image, create Forgejo release with artifacts |
All CI Jobs (ci.yml)
Jobs without explicit dependencies run in parallel.
| Job | Depends On | nox Session(s) | Description |
|---|---|---|---|
lint |
— | nox -s lint + nox -s format -- --check |
Ruff linting + format check |
typecheck |
— | nox -s typecheck |
Pyright strict type checking |
security |
— | nox -s security_scan + nox -s dead_code |
bandit + semgrep + vulture |
quality |
— | nox -s complexity |
Radon complexity analysis |
unit_tests |
— | nox -s unit_tests |
Behave BDD tests |
integration_tests |
— | nox -s integration_tests |
Robot Framework via pabot |
e2e_tests |
— | nox -s e2e_tests |
Robot Framework with real LLM keys |
coverage |
lint, typecheck |
nox -s coverage_report |
Slipcover (fail-under 97%) |
benchmark-regression |
lint, typecheck |
nox -s benchmark_regression |
ASV benchmark regression on PRs |
benchmark-publish |
— | nox -s benchmark (publish) |
ASV publish (push to master/develop) |
build |
— | nox -s build |
Wheel distribution build |
docker |
lint, typecheck, unit_tests, security |
(Docker CLI) | Docker image build + smoke test |
status-check |
All required jobs | — | Consolidation gate for branch protection |
Required Checks for Merge
The status-check job is the single branch-protection gate. It depends on
all required jobs and fails if any of them did not succeed.
These five jobs MUST pass — PR cannot be merged otherwise:
| Job | What it checks |
|---|---|
lint |
Ruff linting passes; code is formatted per ruff standards |
typecheck |
Pyright strict passes; no type errors; no # type: ignore |
security |
No high-severity bandit findings; semgrep rules pass; no dead code |
unit_tests |
All Behave BDD scenarios pass; TDD tag gates pass |
coverage |
Slipcover reports ≥ 97% test coverage |
Informational only (not blocking):
integration_testse2e_testsbenchmark-regression
How to Read CI Results
- Open the PR → scroll to Checks section
- Each job is a separate named check — click any failed job for full logs
status-checkprovides a consolidated summary of all required results- For coverage: look for
COVERAGE OKorCOVERAGE FAILEDin coverage job logs - Benchmark regression: results uploaded as an artifact for manual review
Release Process
# Trigger a release by pushing a version tag:
git tag v<MAJOR>.<MINOR>.<PATCH> # e.g. git tag v1.2.3
git push origin v<MAJOR>.<MINOR>.<PATCH>
The release.yml workflow then runs automatically:
- Builds the wheel via
nox -s build→ uploaded as artifact - Builds the Docker image tagged with the version and
latest - Pushes the Docker image to the configured container registry
- Creates a Forgejo release with the wheel attached as a downloadable artifact
If the release workflow fails
- Verify all required secrets are configured (see table below)
- Confirm
nox -s buildpasses locally - Delete the tag:
git tag -d vX.Y.Z && git push origin :refs/tags/vX.Y.Z - Fix the issue in master, then re-tag and re-push
Required repository secrets
| Secret | Purpose | Example value |
|---|---|---|
CONTAINER_REGISTRY |
Docker registry URL | registry.cleverthis.com/cleveragents/core |
CONTAINER_REGISTRY_USER |
Registry auth username | — |
CONTAINER_REGISTRY_PASSWORD |
Registry auth password | — |
FORGEJO_TOKEN |
API token for creating releases | — |
FORGEJO_URL |
Forgejo instance URL | https://git.cleverthis.com |
Dependency Caching
- CI uses
actions/cache@v3to cache uv package downloads between runs - Cache key:
pyproject.tomlhash - Caches are automatically invalidated when
pyproject.tomlchanges - Reduces CI run time by avoiding redundant package downloads
Nightly Quality Sweep
nightly-quality.yml runs daily at midnight UTC (and can be dispatched manually):
- Extended quality analysis: full complexity and maintainability metrics via Radon
- Corresponds to
nox -s complexity - Results surface issues not caught by standard CI (complexity drift, maintainability index)
Branch Protection
- The
masterbranch is protected - The
status-checkjob is the required check - Direct pushes to
masterare prohibited — all changes via PR - At least 1 approving review required before merge (self-approval permitted)