1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
name: CI
on:
push:
branches:
pull_request:
branches:
workflow_dispatch:
env:
CARGO_TERM_COLOR: always
RUSTFLAGS: -D warnings
jobs:
check:
name: fmt + clippy + test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@stable
with:
components: rustfmt, clippy
- uses: Swatinem/rust-cache@v2
- name: cargo fmt
run: cargo fmt --all --check
# The core crate builds with no ML framework at all, which is what keeps the oracle
# independent. Check that configuration on its own before any adapter is enabled.
- name: cargo clippy (no framework)
run: cargo clippy --all-targets -- -D warnings
- name: cargo test (no framework)
run: cargo test
# The same suite against two burn backends. Running identical checks on more than one
# backend is the point: a backend-specific gradient bug is invisible until you do.
- name: cargo clippy (burn-ndarray)
run: cargo clippy --all-targets --features burn-ndarray -- -D warnings
- name: cargo test (burn-ndarray)
run: cargo test --features burn-ndarray
- name: cargo test (burn-flex)
run: cargo test --features burn-flex
- name: cargo doc
run: cargo doc --no-deps --features burn-ndarray
env:
RUSTDOCFLAGS: -D warnings
# Deliberately not in CI: --features burn-cpu.
#
# That configuration FAILS, and it is supposed to — burn's cpu backend leaks a freed
# allocation into the avg_pool1d backward at even channel counts (tracel-ai/burn#5308), and
# gradcheck detects it. A green CI badge should mean "the tool works", not "the framework is
# perfect", so the backend with a known open defect is run by hand:
#
# cargo test --features burn-cpu --test burn_adapter
#
# Move it into this workflow once the upstream defect is fixed.