Two unrelated cleanups noticed while reviewing #2431. Filing as one issue since both are small.
cc @jensenpat — flagging since you may have context on either.
1. check-windows path filter is too narrow — CI gap
The path filter in .github/workflows/ci.yml only triggers Windows builds when one of these changes:
filters: |
build:
- 'CMakeLists.txt'
- 'third_party/**'
- '.github/workflows/**'
This means src/** changes never trigger a Windows build. Every PR merged in the last few hours (#2412, #2413, #2420, #2422, #2428, #2429, #2431) skipped Windows CI. That includes #2420, which was explicitly a Windows-only bug fix (Win32 QSocketNotifier construction-thread affinity in src/core/*.cpp) — the very kind of change the workflow comment says the Windows builder exists to catch ("to catch MSVC issues before release. (#796 lesson)").
Suggested fix
Add 'src/**' to the build filter:
filters: |
build:
- 'CMakeLists.txt'
- 'third_party/**'
- '.github/workflows/**'
- 'src/**'
Trade-off
Wall-clock cost is real (~7 min Windows builds with cached Qt + sccache), but #2420 just shipped a Win32-only fix the builder couldn't have caught. If runtime cost is the concern, narrower include patterns (src/core/**, src/gui/**, src/models/**) would still cover the common cases while excluding things like src/streamdeck-plugin/.
2. applyInterlockStatus called twice in onStatusReceived
Pre-existing, surfaced during #2431 review. In src/models/RadioModel.cpp inside the object == "interlock" branch:
- Line 3371:
m_transmitModel.applyInterlockStatus(kvs);
- Line 3421:
m_transmitModel.applyInterlockStatus(kvs);
Both calls happen unconditionally in the same status path. Almost certainly idempotent (the model just stores fields from kvs), so no functional impact, but wasteful and confusing for future readers. One of the two should be removed — likely the second one, since the first is co-located with the other interlock-field parsing.
Priority
Both are low-priority cleanups. The CI gap is the one with real consequence — Windows-specific regressions can land silently right now.
73, Jeremy KK7GWY & Claude (AI dev partner)
Two unrelated cleanups noticed while reviewing #2431. Filing as one issue since both are small.
cc @jensenpat — flagging since you may have context on either.
1.
check-windowspath filter is too narrow — CI gapThe path filter in
.github/workflows/ci.ymlonly triggers Windows builds when one of these changes:This means
src/**changes never trigger a Windows build. Every PR merged in the last few hours (#2412, #2413, #2420, #2422, #2428, #2429, #2431) skipped Windows CI. That includes #2420, which was explicitly a Windows-only bug fix (Win32QSocketNotifierconstruction-thread affinity insrc/core/*.cpp) — the very kind of change the workflow comment says the Windows builder exists to catch ("to catch MSVC issues before release. (#796 lesson)").Suggested fix
Add
'src/**'to the build filter:Trade-off
Wall-clock cost is real (~7 min Windows builds with cached Qt + sccache), but #2420 just shipped a Win32-only fix the builder couldn't have caught. If runtime cost is the concern, narrower include patterns (
src/core/**,src/gui/**,src/models/**) would still cover the common cases while excluding things likesrc/streamdeck-plugin/.2.
applyInterlockStatuscalled twice inonStatusReceivedPre-existing, surfaced during #2431 review. In
src/models/RadioModel.cppinside theobject == "interlock"branch:m_transmitModel.applyInterlockStatus(kvs);m_transmitModel.applyInterlockStatus(kvs);Both calls happen unconditionally in the same status path. Almost certainly idempotent (the model just stores fields from
kvs), so no functional impact, but wasteful and confusing for future readers. One of the two should be removed — likely the second one, since the first is co-located with the other interlock-field parsing.Priority
Both are low-priority cleanups. The CI gap is the one with real consequence — Windows-specific regressions can land silently right now.
73, Jeremy KK7GWY & Claude (AI dev partner)