Skip to content

Add Kani smoke CI job (4.1.2)#308

Merged
leynos merged 5 commits into
mainfrom
4-1-2-kani-smoke-ci-job
May 22, 2026
Merged

Add Kani smoke CI job (4.1.2)#308
leynos merged 5 commits into
mainfrom
4-1-2-kani-smoke-ci-job

Conversation

@leynos
Copy link
Copy Markdown
Owner

@leynos leynos commented May 18, 2026

Summary

This branch implements roadmap task (4.1.2) by adding a dedicated kani-smoke Continuous Integration (CI) job. The new job leaves the existing build-test job unchanged, runs only the bounded smoke path on pull requests, and caches Kani tool paths separately from ordinary Cargo artefacts.

Roadmap task: (4.1.2)
Execplan: docs/execplans/4-1-2-kani-smoke-ci-job.md

Review walkthrough

Validation

  • coderabbit review --agent: passed with zero findings after the CI/docs milestone.
  • coderabbit review --agent: passed with zero findings after final roadmap and ExecPlan updates.
  • make check-fmt: passed.
  • make lint: passed.
  • make test: passed.
  • make kani: passed.
  • make markdownlint: passed.
  • make nixie: passed.

Notes

make fmt was attempted because Markdown changed, but it reported pre-existing Markdown lint findings across unrelated documentation and rewrote broad files before failing. Those unrelated formatter edits were restored; focused make markdownlint and make nixie checks pass on the final tree.

No Rust runtime, CLI, OrthoConfig, or user-facing behaviour changed, so no new rstest, rstest-bdd, or end-to-end tests were applicable for this CI-only change.

References

Summary by Sourcery

Add a dedicated Kani smoke GitHub Actions job for pull requests and document its behaviour and roadmap completion.

New Features:

  • Introduce a kani-smoke CI job that runs the Kani smoke verification path on pull requests.

Enhancements:

  • Document the new Kani CI lane and its separate caching strategy in the developer guide.
  • Mark roadmap item 4.1.2 and its subitems as completed and record the corresponding execution plan.

CI:

  • Configure the kani-smoke job to install the pinned Kani toolchain, run make kani, and cache Kani-specific tool data separately from ordinary Cargo artefacts.

Draft the approval-gated ExecPlan for roadmap item `4.1.2`.
The plan scopes the future implementation to a dedicated `kani-smoke`
CI job, keeps `build-test` unchanged, and records the cache, review,
and validation boundaries for the implementation phase.
Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @leynos, you have reached your weekly rate limit of 2500000 diff characters.

Please try again later or upgrade to continue using Sourcery

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 18, 2026

Review Change Stack

Walkthrough

The PR implements a dedicated kani-smoke GitHub Actions job that runs Kani smoke tests on pull requests, installing the pinned Kani toolchain and caching its downloads separately from ordinary Cargo artefacts. The changes document the implementation via ExecPlan, update the CI workflow, update developer guidance, and mark the roadmap task complete.

Changes

Kani-smoke CI job and documentation

Layer / File(s) Summary
ExecPlan and roadmap completion
docs/execplans/4-1-2-kani-smoke-ci-job.md, docs/roadmap.md
Living ExecPlan document records the full implementation scope, constraints, tolerances, risks, execution progress, discoveries, decisions, staged plan, concrete implementation steps, acceptance criteria, and PR preparation. Task 4.1.2 marked complete in roadmap with all subtasks finished: kani-smoke job added, build-test unchanged, smoke tests run on pull requests only, Kani caching isolated.
Kani-smoke CI job implementation
.github/workflows/ci.yml
New kani-smoke job added to workflow, running only on pull requests with stable Rust toolchain. Caches Kani tool directories using key derived from tools/kani/VERSION, installs pinned Kani via scripts/install-kani.sh, and executes make kani smoke test.
Developer guide update
docs/developers-guide.md
Formal-verification section updated to document the kani-smoke pull-request CI job. Specifies job installs pinned Kani via existing scripts, runs only smoke check (not full/coverage), and uses isolated cache key. Previous statement that formal verification remains opt-in removed.

Possibly related PRs

  • leynos/netsuke#305: The main PR's new CI kani-smoke job runs make kani and installs pinned Kani via scripts/install-kani.sh, directly wiring together the Makefile targets and installer tooling added in PR #305.

Suggested labels

Roadmap

Poem

Kani smoke drifts through the pull request gates,
Pinned and cached, it validates,
No build-test disturbed in the flow,
The roadmap task completes its glow—
Formal verification takes its smoke. 🔍✨


Caution

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

  • Ignore

❌ Failed checks (2 errors)

Check name Status Explanation Resolution
Unit Architecture ❌ Error Checkout action at line 76 lacks persist-credentials: false, leaving GitHub token in ambient environment. Cache-miss fallibility is implicit, not explicitly handled at architectural boundary. Add persist-credentials: false to line 76 checkout action. Document or validate cache restore before install-kani.sh to make fallible cache operation explicit.
Security And Privacy ❌ Error The checkout step at line 76 lacks persist-credentials: false, allowing the GitHub token to persist in the job environment for subsequent steps, creating an unnecessary credential exposure risk. Add persist-credentials: false to the actions/checkout step on line 76 to prevent token persistence in the kani-smoke job.
✅ Passed checks (16 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Add Kani smoke CI job (4.1.2)' directly aligns with the primary change and includes the required roadmap item reference.
Description check ✅ Passed The description comprehensively documents the implementation of roadmap task 4.1.2, detailing the kani-smoke CI job, documentation updates, and validation results.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Testing (Overall) ✅ Passed PR introduces no new functionality requiring tests; changes are purely CI workflow and documentation updates with no runtime behaviour changes.
User-Facing Documentation ✅ Passed PR is infrastructure/developer-facing only (CI job, developer docs, roadmap). PR explicitly states no user-facing behaviour changes. No update to users-guide.md required.
Developer Documentation ✅ Passed Tooling documented in developers-guide.md with cache strategy; design document exists; ExecPlan marked COMPLETE with Outcomes; roadmap 4.1.2 complete; decisions recorded.
Module-Level Documentation ✅ Passed PR modifies only configuration and documentation files (GitHub Actions workflow, Markdown docs); no code modules (Rust, Python, JavaScript, TypeScript) were added or modified.
Testing (Unit And Behavioural) ✅ Passed PR changes only CI workflow YAML and documentation; no new Rust runtime code, CLI behaviour, or system-level contracts were introduced, so testing requirement does not apply.
Testing (Property / Proof) ✅ Passed The PR adds CI infrastructure only—no new Rust code, invariants, or proofs. The ExecPlan explicitly forbids "Kani proof harnesses, Proptest tests, or new Rust verification logic."
Testing (Compile-Time / Ui) ✅ Passed PR makes only CI workflow and documentation changes with no code, compile-time, or output changes; trybuild/snapshot tests not applicable.
Domain Architecture ✅ Passed PR only modifies CI workflow (.github/workflows/ci.yml) and documentation files; no domain code, adapters, or business logic changes. Domain architecture check not applicable.
Observability ✅ Passed Scripts output diagnostics with explicit error handling. GitHub Actions provides logs and step tracking. Observability requirements apply to production operations, not CI tooling.
Performance And Resource Use ✅ Passed The kani-smoke job uses bounded caches, deterministic version validation without loops, event filtering, and expected 3–6 minutes runtime well under the 20-minute tolerance.
Concurrency And State ✅ Passed The kani-smoke job isolates state via explicit CARGO_HOME/KANI_HOME variables and separate cache keys; parallel execution is safe with no shared mutable state or synchronisation needed.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch 4-1-2-kani-smoke-ci-job

Comment @coderabbitai help to get the list of available commands and usage tips.

Add a dedicated `kani-smoke` pull-request job that installs the
repository-pinned Kani version and runs the bounded smoke target.
Keep `build-test` unchanged while caching Kani tool paths separately
from ordinary Cargo artefacts.

Document the CI lane for contributors, update the living ExecPlan with
validation evidence, and mark roadmap item `4.1.2` complete.
codescene-delta-analysis[bot]

This comment was marked as outdated.

Mark the ExecPlan complete after the implementation commit, branch push,
and draft pull request refresh. Preserve the validation record so the plan
can be used as the final delivery log for roadmap item `4.1.2`.
@leynos leynos marked this pull request as ready for review May 20, 2026 19:45
@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai Bot commented May 20, 2026

Reviewer's Guide

Adds a new pull-request-only kani-smoke CI job that installs a pinned Kani toolchain, runs the bounded smoke path via make kani, caches Kani artefacts separately from ordinary Cargo artefacts, and documents this lane plus marks roadmap item 4.1.2 complete with an accompanying ExecPlan.

Flow diagram for kani-smoke CI job steps

flowchart TD
  A["Start kani-smoke job (pull_request)"] --> B["actions/checkout@v4.1.2"]
  B --> C["Setup Rust via setup-rust action (toolchain: stable)"]
  C --> D["Set CARGO_HOME=.kani-cargo and KANI_HOME=.kani-home"]
  D --> E["Restore/save cache for .kani-cargo and .kani-home<br>(actions/cache with key from tools/kani/VERSION)"]
  E --> F["scripts/install-kani.sh"]
  F --> G["make kani (bounded Kani smoke path)"]
  G --> H["Job complete"]
Loading

File-Level Changes

Change Details Files
Introduce a dedicated kani-smoke GitHub Actions job that reuses existing Rust setup and Kani tooling, runs only the smoke path, and isolates Kani caches from normal Cargo caches.
  • Add a kani-smoke job under jobs: that runs only on pull_request events and uses ubuntu-latest with read-only contents permissions.
  • Set job-local CARGO_HOME and KANI_HOME environment variables pointing into the workspace to keep Kani tooling isolated.
  • Reuse the shared setup-rust composite action pinned by SHA with a stable toolchain for this job.
  • Add an actions/cache step pinned by SHA that caches .kani-cargo and .kani-home keyed by OS and the contents of tools/kani/VERSION.
  • Invoke scripts/install-kani.sh to install the pinned Kani version and then run make kani as the smoke verification step.
.github/workflows/ci.yml
Document the new Kani CI lane and caching conventions for contributors.
  • Update the formal-verification section to remove the forward-looking note about a future Kani CI job, since it now exists.
  • Describe that pull requests run a kani-smoke CI job alongside build-test, that it installs the pinned Kani with scripts/install-kani.sh, and that it runs only make kani (not the full suite or other CI tasks).
  • Explain that the Kani CI job uses a Kani-specific cache key derived from tools/kani/VERSION and caches job-local Kani Cargo and support-file homes separately from ordinary Cargo artefacts.
docs/developers-guide.md
Mark roadmap item 4.1.2 and its subitems as complete and align roadmap status with the implemented CI job.
  • Flip roadmap item 4.1.2 from unchecked to checked to indicate completion.
  • Mark the three sub-bullets (keep build-test unchanged, run only bounded smoke harnesses on PRs, and cache Kani tools separately) as completed.
  • Ensure references to the CI design section remain intact while reflecting the now-implemented state.
docs/roadmap.md
Add a detailed ExecPlan document capturing constraints, risks, decisions, and validation for roadmap task 4.1.2.
  • Introduce a new ExecPlan file for 4.1.2 that records purpose, constraints, tolerances, risks, progress log, surprises, and decisions around the Kani smoke CI job.
  • Describe the intended kani-smoke job structure, including environment variables, cache strategy, and command sequence, as a reference for reviewers and future work.
  • Record validation steps (make targets, CodeRabbit review, CI expectations) and mark the plan as COMPLETE with outcomes and retrospective notes.
docs/execplans/4-1-2-kani-smoke-ci-job.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 3 issues

Prompt for AI Agents
Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path=".github/workflows/ci.yml" line_range="87" />
<code_context>
+        uses: leynos/shared-actions/.github/actions/setup-rust@6b13b519f99c5b461be8cc21ecf19c2ec5907b9c
+        with:
+          toolchain: stable
+      - name: Cache Kani tools
+        uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830  # v4.3.0
+        with:
+          path: |
+            .kani-cargo
+            .kani-home
+          key: ${{ runner.os }}-kani-${{ hashFiles('tools/kani/VERSION') }}
+      - name: Install Kani
+        run: scripts/install-kani.sh
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider including installer or script inputs in the cache key to avoid stale Kani tool caches.

Since the key only uses `runner.os` and `tools/kani/VERSION`, changes to `scripts/install-kani.sh` (or other install-time inputs) won’t invalidate the cache unless `VERSION` is bumped. To avoid incompatible tool caches, consider adding a hash or version from the installer (e.g., via `hashFiles` or `restore-keys`) to the cache key.

```suggestion
          key: ${{ runner.os }}-kani-${{ hashFiles('tools/kani/VERSION', 'scripts/install-kani.sh') }}
```
</issue_to_address>

### Comment 2
<location path="docs/execplans/4-1-2-kani-smoke-ci-job.md" line_range="1" />
<code_context>
+# 4.1.2. Add a Kani smoke CI job
+
+This ExecPlan (execution plan) is a living document. The sections
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym “CI” appears in the title before “Continuous Integration (CI)” is defined later in the document.

To comply with the acronym rule, expand “CI” the first time it appears. For example:

"Add a Kani smoke Continuous Integration (CI) job"

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

### Comment 3
<location path="docs/execplans/4-1-2-kani-smoke-ci-job.md" line_range="49" />
<code_context>
+- Reuse the repository pin in `tools/kani/VERSION` and the existing
+  `scripts/install-kani.sh` and `scripts/check-kani-version.sh` paths where
+  possible.
+- Keep OrthoConfig unchanged. This is CI wiring, not a new CLI flag, runtime
+  configuration field, localized help string, or configuration precedence
+  rule.
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym “CLI” is used here without being defined on first use in the document.

Please expand “CLI” on its first occurrence in the document, for example “command-line interface (CLI) flag”, and then use “CLI” thereafter.

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread .github/workflows/ci.yml Outdated
Comment thread docs/execplans/4-1-2-kani-smoke-ci-job.md Outdated
Comment thread docs/execplans/4-1-2-kani-smoke-ci-job.md Outdated
@coderabbitai coderabbitai Bot added the Roadmap label May 20, 2026
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/ci.yml:
- Line 76: The checkout step currently uses actions/checkout without disabling
credential persistence; update the checkout action invocation (the
actions/checkout@... entry) to add a with: persist-credentials: false setting so
the GITHUB_TOKEN is not left configured for subsequent steps; locate the
actions/checkout line and add the persist-credentials: false option under its
with block for that step.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 0915710e-317a-4bf4-b534-e946a91b38a3

📥 Commits

Reviewing files that changed from the base of the PR and between f59a7be and 538e04b.

📒 Files selected for processing (4)
  • .github/workflows/ci.yml
  • docs/developers-guide.md
  • docs/execplans/4-1-2-kani-smoke-ci-job.md
  • docs/roadmap.md

Comment thread .github/workflows/ci.yml
Set `persist-credentials: false` on the `kani-smoke` checkout step so
the pull-request verification job does not leave the GitHub token in the
repository configuration for later steps.
codescene-delta-analysis[bot]

This comment was marked as outdated.

Include the Kani installer script in the smoke job cache key so changes
to install-time inputs invalidate stale tool caches. Expand acronyms on
first use in the Kani smoke ExecPlan to match documentation review rules.
@leynos
Copy link
Copy Markdown
Owner Author

leynos commented May 22, 2026

@coderabbitai Have the following now been resolved?

Annul any requirements that violate the en-GB-oxendict spelling (-ize / -yse / -our) conventions (for example a request to replace "normalize" with "normalise" or "artefact" with "artifact"), or where the requirement unnecessarily increases cyclomatic complexity.

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path=".github/workflows/ci.yml" line_range="87" />
<code_context>
+        uses: leynos/shared-actions/.github/actions/setup-rust@6b13b519f99c5b461be8cc21ecf19c2ec5907b9c
+        with:
+          toolchain: stable
+      - name: Cache Kani tools
+        uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830  # v4.3.0
+        with:
+          path: |
+            .kani-cargo
+            .kani-home
+          key: ${{ runner.os }}-kani-${{ hashFiles('tools/kani/VERSION') }}
+      - name: Install Kani
+        run: scripts/install-kani.sh
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider including installer or script inputs in the cache key to avoid stale Kani tool caches.

Since the key only uses `runner.os` and `tools/kani/VERSION`, changes to `scripts/install-kani.sh` (or other install-time inputs) won’t invalidate the cache unless `VERSION` is bumped. To avoid incompatible tool caches, consider adding a hash or version from the installer (e.g., via `hashFiles` or `restore-keys`) to the cache key.

```suggestion
          key: ${{ runner.os }}-kani-${{ hashFiles('tools/kani/VERSION', 'scripts/install-kani.sh') }}
```
</issue_to_address>

### Comment 2
<location path="docs/execplans/4-1-2-kani-smoke-ci-job.md" line_range="1" />
<code_context>
+# 4.1.2. Add a Kani smoke CI job
+
+This ExecPlan (execution plan) is a living document. The sections
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym “CI” appears in the title before “Continuous Integration (CI)” is defined later in the document.

To comply with the acronym rule, expand “CI” the first time it appears. For example:

"Add a Kani smoke Continuous Integration (CI) job"

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

### Comment 3
<location path="docs/execplans/4-1-2-kani-smoke-ci-job.md" line_range="49" />
<code_context>
+- Reuse the repository pin in `tools/kani/VERSION` and the existing
+  `scripts/install-kani.sh` and `scripts/check-kani-version.sh` paths where
+  possible.
+- Keep OrthoConfig unchanged. This is CI wiring, not a new CLI flag, runtime
+  configuration field, localized help string, or configuration precedence
+  rule.
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym “CLI” is used here without being defined on first use in the document.

Please expand “CLI” on its first occurrence in the document, for example “command-line interface (CLI) flag”, and then use “CLI” thereafter.

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

@leynos
Copy link
Copy Markdown
Owner Author

leynos commented May 22, 2026

@coderabbitai Have the following failed checks now been resolved?

If further work is required, please provide an AI agent prompt for the remaining work to be done to address these failures.

Do not treat warnings as optional or aspirational. Where a change is out of scope for this PR, propose a GitHub issue unless one exists already.

❌ Failed checks (2 errors)

Check name Status Explanation Resolution
Unit Architecture ❌ Error Checkout action at line 76 lacks persist-credentials: false, leaving GitHub token in ambient environment. Cache-miss fallibility is implicit, not explicitly handled at architectural boundary. Add persist-credentials: false to line 76 checkout action. Document or validate cache restore before install-kani.sh to make fallible cache operation explicit.
Security And Privacy ❌ Error The checkout step at line 76 lacks persist-credentials: false, allowing the GitHub token to persist in the job environment for subsequent steps, creating an unnecessary credential exposure risk. Add persist-credentials: false to the actions/checkout step on line 76 to prevent token persistence in the kani-smoke job.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 22, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check current state of ci.yml around the cache key
echo "=== .github/workflows/ci.yml (kani cache section) ==="
rg -n "kani|install-kani|VERSION|cache" .github/workflows/ci.yml -A2 -B2

echo ""
echo "=== First 60 lines of execplan ==="
head -60 docs/execplans/4-1-2-kani-smoke-ci-job.md

echo ""
echo "=== Lines around 'CLI' first occurrence ==="
rg -n "CLI\|CI\b" docs/execplans/4-1-2-kani-smoke-ci-job.md | head -20

Length of output: 4261


@leynos: Yes, all three have been resolved:

  1. Comment 1 (cache key)scripts/install-kani.sh is now included in the hashFiles call, so the cache key correctly invalidates when the installer changes.

  2. Comment 2 ("CI" acronym) — The ExecPlan title now reads "Add a Kani smoke Continuous Integration (CI) job".

  3. Comment 3 ("CLI" acronym) — The first occurrence now reads "command-line interface (CLI) flag".

[resolve]

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 22, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check the current state of the kani-smoke job in ci.yml
cat -n .github/workflows/ci.yml | grep -A 40 "kani-smoke"

Length of output: 1222


@leynos Both failed checks are resolved:

Check Resolution
Unit Architecture persist-credentials: false is present at line 78 of the checkout step; the cache key now includes scripts/install-kani.sh in hashFiles. ✅
Security And Privacy persist-credentials: false prevents token persistence in the kani-smoke job environment. ✅

No further work is required for these failures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant