Skip to content

CI: run the bounded Kani harness set in the kani-smoke PR job #445

Description

@lodyai

Background

Roadmap 4.1.2 shipped the dedicated kani-smoke CI job (PR #308). As scoped
at the time, the job runs only the bounded smoke path — currently
make install-kani followed by make kani-check (a Kani version check) —
because no proof harnesses existed yet. Populating the bounded harness set was
explicitly deferred to the 4.2.* roadmap work (see
docs/execplans/4-1-2-kani-smoke-ci-job.md, Risk section).

Current gap

4.2.1 and 4.2.2 have since landed real harnesses (nine IR harnesses plus
four cycle-canonicalization harnesses; 13 #[kani::proof] total). However, the
kani-smoke PR job still runs only make kani-check, so those bounded
harnesses are not exercised on pull requests.

Proposed work

  • Point the kani-smoke PR job at the bounded harness set (e.g. make kani-ir
    / make kani-full) instead of, or in addition to, make kani-check.
  • Keep the existing build-test job unchanged and preserve the isolated Kani
    cache (.kani-cargo / .kani-home, keyed on tools/kani/VERSION).
  • Confirm the cold-run wall-clock stays within the execplan tolerance (the
    4.1.2 plan flagged a 20-minute ceiling).

References

  • docs/roadmap.md4.1.2 (third subtask signposts this issue).
  • docs/execplans/4-1-2-kani-smoke-ci-job.md.
  • .github/workflows/ci.ymlkani-smoke job.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestlowAin't annoying anyone but the QA departmenttesting

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions