Update CI workflow for Rust and Python builds

[manoelhc]

Summary by Sourcery

Migrate CI workflows to self-hosted runners with a shared dependency setup job, add a draft pull request build job for Rust/Python wheels, and gate the Python build job to only run on non-draft pull requests.

CI:

• Add a shared install-deps job on self-hosted runners to provision build environments.
• Update Rust, Python, and lint jobs to run on self-hosted runners and depend on the shared setup job.
• Restrict the Python build-and-test job to non-draft pull requests and introduce a separate build-draft workflow for draft PRs using pyenv and maturin.

[sourcery-ai]

Reviewer's Guide

CI workflow is refactored to run all jobs on a self-hosted (rpi) runner, gate the main Python matrix for only non-draft PRs, and add a dedicated draft PR build job that combines Rust and Python smoke tests using pyenv-based Python setup and caching.

Flow diagram for updated CI job structure and gating

flowchart TD
  trigger[GitHub pull_request]
  mainpush[GitHub push to main/develop]

  subgraph Conditions
    draft{"pull_request is draft"}
    nonDraft{"pull_request is non-draft"}
  end

  trigger --> draft
  trigger --> nonDraft
  mainpush --> install_deps

  install_deps[install-deps job\nself-hosted rpi]
  rust[rust-build-and-test\nneeds install-deps]
  pyMatrix[python-build-and-test\nnon-draft PR only\nneeds install-deps]
  draftBuild[build-draft\ndraft PR only\nneeds install-deps]
  lintJob[lint job\nneeds install-deps]

  draft -->|true| draftBuild
  draft -->|false| nonDraft
  nonDraft --> install_deps

  install_deps --> rust
  install_deps --> pyMatrix
  install_deps --> draftBuild
  install_deps --> lintJob

  classDef selfHosted fill:#e3f2fd,stroke:#1e88e5
  class install_deps,rust,pyMatrix,draftBuild,lintJob selfHosted

Loading

File-Level Changes

Change	Details	Files
Introduce shared dependency installation job for self-hosted runner and move Rust, Python, and lint jobs onto it.	Add global PYENV_ROOT env configuration at workflow top level. Add install-deps job using a debian runner setup action with full packages and sudo. Update rust-build-and-test job to depend on install-deps and run on self-hosted instead of ubuntu-latest. Update python-build-and-test job to depend on install-deps and run on self-hosted instead of a matrix OS, adding explicit permissions. Update lint job to depend on install-deps and run on self-hosted instead of ubuntu-latest.	.github/workflows/ci.yml
Gate main Python matrix build to non-draft pull requests and introduce a separate draft/manual build job with combined Rust and Python smoke tests on rpi.	Add conditional to python-build-and-test to only run for pull_request events where the PR is not draft. Add build-draft job that runs only for draft pull requests on self-hosted runner with read-only contents permission. Implement pyenv-based Python setup in build-draft with caching of installed versions and environment export. Within build-draft, install Rust toolchain, cache Cargo dependencies, build the Python package with maturin, install the built wheel, run a basic import test, and optionally run pytest-based tests if present.	.github/workflows/ci.yml
Add project-level Python version pinning for pyenv-based builds.	Create .python-version file to define the Python version used by pyenv in CI.	.python-version

---

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

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (2)

• .github/workflows/ci.yml is excluded by none and included by none
• .python-version is excluded by none and included by none

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 3d8937f0-236c-4c8a-86e2-d16566e45562

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch manoelhc-patch-4

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[deepsource-io]

DeepSource Code Review

We reviewed changes in d979786...d2a4a56 on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.

See full review on DeepSource ↗

PR Report Card

Overall Grade

Security   Reliability   Complexity   Hygiene

Code Review Summary

Analyzer	Status	Updated (UTC)	Details
Python		Jun 30, 2026 4:05p.m.	Review ↗
Rust		Jun 30, 2026 4:05p.m.	Review ↗

---

Important

AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• 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.

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>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}