feat(local): detect dependency-cascade failures generally, not just RcppParallel #128
Loading…
Reference in a new issue
No description provided.
Delete branch "t3code/detect-dependency-cascades"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why (from the #127 trial-build gate)
The gate did its job: 0/3 passed, merge blocked. The log showed why -- BFpack, BayesERtools, GMLTM all fail while building their shared dependency
rstan, not in their own code:So the per-package
-DTBB_INTERFACE_NEWmakevars entries the classifier proposed are useless for these packages -- they're blocked onrstan(which already has a registry entry). This is the same dependency cascade the RcppParallelapplies_toguard catches, buttbb-stddef-removedis a generic signature with no such pin, so ~73 Stan packages kept getting proposed.What
Generalise cascade detection beyond the RcppParallel special case:
failing_dependency(error_text, package)-- when the log names a different package as the one that failed to compile (Failed to build source package X,compilation failed for package 'X',dependency 'X' ... not available), that package is the real cause.build_triage_report()now blocks any package whose every failing build is such a cascade: reported asblocked_onthat dependency, never proposed a bogus per-package entry. A package that fails in its own compilation is still proposed.applies_to(RcppParallel) and data-driven (rstan) cases are unified into oneblocked_packages/blocked_onmodel; the report, proposer, andblocked_summarycount the actually-blocked packages, and the blocked note shows even when a group also has genuine proposals.Effect
Next auto-apply run will stop proposing the rstan-blocked Stan packages (and any future dependency cascade) and surface them as "blocked on rstan" instead. Fixing
rstanonce clears the whole cluster.Verification
failing_dependency(cascade vs own-compile vs none), and an end-to-end split where BFpack/GMLTM (blocked on rstan) are not proposed while an own-compile package still is.Refs #120, #127. (Separate follow-ups: fixing rstan's build itself, and quieting the gate's metadata-DB retry storm -- both root-caused to bincraft.)
The first trial-build gate run correctly went red: the 10 auto-proposed tbb-stddef packages (BFpack, BayesERtools, GMLTM, ...) all fail while building their shared `rstan` dependency, not in their own code -- the `tbb/tbb_stddef.h` error is in rstan's Module.cpp. So a per-package makevars entry is useless for them; they are blocked on rstan (which already has an entry). This is the same cascade the RcppParallel `applies_to` guard catches, but the tbb-stddef signature is generic and had no such pin. Add `failing_dependency(error_text, package)`: when the log shows a DIFFERENT package failed to compile ("Failed to build source package X", "compilation failed for package 'X'", ...), that package is the real cause. build_triage_report now blocks any package whose every failing build is such a cascade -- reported as blocked_on the dependency, never proposed a bogus entry. A package that fails in its OWN compilation is still proposed. This unifies the applies_to and data-driven cases into one `blocked_packages` / `blocked_on` model. - report/proposer/blocked_summary now count the actually-blocked packages - blocked note shows even when a group also has genuine proposals - tests cover the rstan-cascade vs own-compile split (with the real log strings)