forked from openhardwaremonitor/openhardwaremonitor
-
Notifications
You must be signed in to change notification settings - Fork 0
146 lines (130 loc) · 5.54 KB
/
Copy pathci.yml
File metadata and controls
146 lines (130 loc) · 5.54 KB
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
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
name: CI
# Build-validates the native SensorView app (eframe/egui) on all three target
# OSes, runs the Rust tests, and uploads the produced installers
# (.exe, .deb/.AppImage, .dmg) as workflow artifacts.
# Publishing tagged releases is handled by release.yml.
on:
push:
branches: [master]
paths: ["app/**", ".github/workflows/ci.yml"]
pull_request:
paths: ["app/**", ".github/workflows/ci.yml"]
workflow_dispatch:
jobs:
build:
strategy:
fail-fast: false
matrix:
include:
- platform: windows-latest
formats: nsis
- platform: ubuntu-22.04
formats: deb,appimage
- platform: macos-latest
formats: dmg
runs-on: ${{ matrix.platform }}
defaults:
run:
working-directory: app
steps:
- uses: actions/checkout@v5
- name: Install Linux build dependencies
if: matrix.platform == 'ubuntu-22.04'
run: |
sudo apt-get update
sudo apt-get install -y \
libgtk-3-dev \
libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev \
libxkbcommon-dev libwayland-dev libssl-dev
- uses: dtolnay/rust-toolchain@stable
- uses: Swatinem/rust-cache@v2
with:
workspaces: app -> target
- name: Publish LHM bridge sidecar (Windows)
if: matrix.platform == 'windows-latest'
run: dotnet publish sidecar -c Release -o sidecar/publish
# Failing test names are echoed as ::error:: annotations so they show up
# on the PR and in the checks API. Without this a failure is just
# "exit code 101" and you have to open the raw log to learn anything —
# which is painful when the failure only reproduces on one runner OS.
- name: Run tests
shell: bash
run: |
set +e
cargo test --no-fail-fast 2>&1 | tee test-output.txt
status=${PIPESTATUS[0]}
if [ "$status" -ne 0 ]; then
echo "::group::Failure summary"
grep -E '^test .* FAILED$' test-output.txt | while IFS= read -r line; do
echo "::error::$line"
done
# The panic messages themselves, which say *why*.
grep -E "panicked at|assertion .* failed" test-output.txt | head -20 |
while IFS= read -r line; do echo "::error::$line"; done
echo "::endgroup::"
fi
exit "$status"
# The web tier's correctness argument rests on never holding a lock guard
# across an await; make that a build failure rather than a review habit.
- name: Clippy
run: |
rustup component add clippy
cargo clippy --all-targets -- -D warnings -D clippy::await_holding_lock
# Every shipping configuration, enumerated explicitly.
#
# `--no-default-features` used to mean "GUI without the web tier". Making
# the GUI itself optional silently changed it to mean "no front end at
# all", so the combinations are spelled out rather than left to drift with
# one flag. Each is a configuration a user can actually get:
#
# cli headless binary for servers and containers (no egui)
# cli+web the same, plus the dashboard — what `daemon` is for
# gui desktop app with no listening socket
# cli+push push telemetry to a collector, no dashboard
# gui+web the previous meaning of this check
# cli+tui `sensorview top` without a dashboard
# cli+web+push+tui the full headless deployment
#
# Clippy rather than check: a headless build is shipped, so it has to be
# warning-clean, not merely compilable.
- name: Clippy — every feature combination
shell: bash
run: |
set -e
for features in "" "web" "gui" "push" "tui" "gui,web" "web,push,tui"; do
echo "::group::--no-default-features --features '$features'"
cargo clippy --no-default-features --features "$features" \
--all-targets -- -D warnings
echo "::endgroup::"
done
# The headless binary is the reason the GUI is optional; prove it still
# runs and that a bare invocation prints help rather than hanging.
- name: Smoke-test the headless build
shell: bash
run: |
cargo build --no-default-features --features web
./target/debug/sensorview --help
./target/debug/sensorview sensors --filter cpu || true
- name: Build (release)
run: cargo build --release
# The portable artifact is only built by release.yml, so without this it
# would break silently between tags and only be discovered while cutting
# a release. Windows-only: the embedded sidecar is a no-op elsewhere.
- name: Build the portable exe (Windows)
if: matrix.platform == 'windows-latest'
run: cargo build --release --features portable --target-dir target-portable
- name: Install cargo-packager
run: cargo install cargo-packager --version 0.11.8 --locked
- name: Package installers
run: cargo packager --release --formats ${{ matrix.formats }} --verbose
- name: Upload installers
uses: actions/upload-artifact@v4
with:
name: sensorview-${{ matrix.platform }}
path: |
app/target/release/*-setup.exe
app/target/release/*.deb
app/target/release/*.AppImage
app/target/release/*.dmg
app/target/release/SensorView*.exe
if-no-files-found: warn