Update CI workflow for Rust and Python builds#69
Conversation
Reviewer's GuideCI workflow now targets an rpi runner for Rust builds and splits Python jobs so that full Python build-and-test runs only on non-draft, non-manual PRs, while a new build-only matrix job (including Rust+maturin build and import/tests) runs for draft or manually-triggered PRs on rpi. Flow diagram for CI job selection based on PR stateflowchart TD
Start["pull_request event"] --> CheckManual
CheckManual{manual_workflow == true?} -->|yes| RunBuildDraftManual
CheckManual -->|no| CheckDraft
CheckDraft{draft == true?} -->|yes| RunBuildDraftDraft
CheckDraft -->|no| RunPythonBuildAndTest
RunBuildDraftManual["Run build_draft job\n(Rust+Python build matrix on rpi)"] --> End
RunBuildDraftDraft["Run build_draft job\n(Rust+Python build matrix on rpi)"] --> End
RunPythonBuildAndTest["Run python_build_and_test job\n(full Python build and test on matrix.os)"] --> End
subgraph Always_Runs
RustJob["rust_build_and_test job\n(on rpi)"]
end
Start --> RustJob
End["workflow jobs complete"]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Note
|
|
|
Overall Grade |
Security Reliability Complexity Hygiene |
Code Review Summary
| Analyzer | Status | Updated (UTC) | Details |
|---|---|---|---|
| Python | Mar 12, 2026 11:31a.m. | Review ↗ | |
| Rust | Mar 12, 2026 11:31a.m. | Review ↗ |
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- The job
ifconditions referencegithub.event.pull_request.manual_workflow, which is not a standard field on the pull_request event; if you need to distinguish manual vs normal runs, consider usingworkflow_dispatchinputs orgithub.event_nameinstead. - Since
draftalready indicates draft PRs on pull_request events, you may not need a separatebuild-draftjob; instead, consider simplifying by using a single Python job with anif: !github.event.pull_request.draft(or similar) condition or by sharing steps between the two jobs to avoid duplication.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The job `if` conditions reference `github.event.pull_request.manual_workflow`, which is not a standard field on the pull_request event; if you need to distinguish manual vs normal runs, consider using `workflow_dispatch` inputs or `github.event_name` instead.
- Since `draft` already indicates draft PRs on pull_request events, you may not need a separate `build-draft` job; instead, consider simplifying by using a single Python job with an `if: !github.event.pull_request.draft` (or similar) condition or by sharing steps between the two jobs to avoid duplication.
## Individual Comments
### Comment 1
<location> `.github/workflows/ci.yml:51` </location>
<code_context>
run: cargo test --release
python-build-and-test:
+ if: github.event.pull_request.manual_workflow == false && github.event.pull_request.draft == false
name: Python Build and Test
runs-on: ${{ matrix.os }}
</code_context>
<issue_to_address>
**issue (bug_risk):** Accessing `github.event.pull_request.manual_workflow` is likely invalid and may break non-PR triggers.
`pull_request` events don’t expose a `manual_workflow` field, so this condition will always be false on PRs and may throw `Cannot index into a null value` on non-PR events where `github.event.pull_request` is null (e.g. `push`, `workflow_dispatch`). If you need a manual flag, use `workflow_dispatch` inputs or labels, and guard PR-only fields with something like:
```yaml
if: github.event_name == 'pull_request' && !github.event.pull_request.draft
```
</issue_to_address>
### Comment 2
<location> `.github/workflows/ci.yml:112-113` </location>
<code_context>
fi
shell: bash
continue-on-error: true
+ build-draft:
+ if: github.event.pull_request.manual_workflow == true || github.event.pull_request.draft == true
+ runs-on: ${{ matrix.os }}
+ strategy:
</code_context>
<issue_to_address>
**issue (bug_risk):** The `build-draft` condition has the same `manual_workflow` / null pull_request access problem as the main Python job.
This reuses the unguarded access to `github.event.pull_request.manual_workflow` / `.draft`. On non-PR events, `github.event.pull_request` is `null`, so this condition can fail evaluation, and `manual_workflow` is not part of the standard PR payload. Consider restricting this to PR events, e.g.
```yaml
if: github.event_name == 'pull_request' && github.event.pull_request.draft == true
```
and handle any "manual workflow" behavior via a separate mechanism (such as `workflow_dispatch` inputs or labels).
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Updated CI workflow to run on Raspberry Pi and simplified Python setup.
Specify pip version for Python setup
Added a new job for installing dependencies before other jobs.
Remove pyenv directory before setting up Python in CI workflows.
|
@copilot Run |
Removed redundant pyenv cleanup commands from CI workflow.
Refactor pyenv setup to ensure proper installation and path configuration.
Removed redundant PYENV_ROOT and PATH exports.
Summary by Sourcery
Update CI workflows to run Rust and Python builds on the rpi runner and to separate behaviour for draft/manual pull requests.
CI: