[nightly-verify] main is red
- Dominant language
- Rust
- Stars
- 467
- Forks
- 54
- Avg merge
- 4h 25m
- Merged PRs (30d)
- 310
Description
The nightly `make verify` run on `self-hosted-macos-26-arm64` failed. Check the first failing step in the run log before reading the gate table below: a setup step that fails leaves the gates reporting `failure` for want of a toolchain rather than because the code is red.
| Field | Value |
|---|---|
| `verify` job result | `failure` |
| `make verify-fmt` | `success` |
| `make verify-clippy` | `success` |
| `make verify-test` | `failure` |
| `make verify-test-video` | `success` |
| Trigger | `schedule` |
Duration of the `verify` job: **16m2s**.
Commit: `878f72a53564b2849bbe4ae0be1be818ca933582`
Run: https://github.com/lablup/mlxcel/actions/runs/33666326398
An `unknown` step outcome means the job published no outcome for that step. A `timeout-minutes` cancellation still publishes them, so `unknown` points at the runner being lost outright rather than at the budget.
Reproduce locally with `make verify` (or the single failing target above).
This issue is reused by subsequent nightly reports of the same kind while it stays open.
Contributor guide
Research direction
Start with the linked GitHub Actions run and inspect the first failing step, rather than relying on the gate table. Reproduce with `make verify` or the failing `make verify-test` target. Done means the nightly `verify` job passes on `self-hosted-macos-26-arm64` and the failure no longer recurs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, macos, rust
- Domain
- ci-cd, devops, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100