You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TST: stop treating warnings as errors in oldestdeps CI #18853
Rationale: treating warnings as errors in CI is crucial to ensure that deprecation warnings from our dependencies are not ignored, and that we don't write self-warning code unintentionally.
However, in oldestdeps runs, the intended environment should be predictible and stable (requires #18782), so deprecation warning should not be treated as (incoming) breaking changes. I would argue that in these conditions, warnings are actually perfectly acceptable, especially considering that they might be triggered by and from all sorts of dependencies outside our direct control.
The alternative, and current way forward as I'm writing this (and #18782 is an on-going project), is to filter numerous warnings that are seen in oldestdeps CI, which isn't ideal by any account.
For instance, this is what has been blocking discussions around #18780
I'm opening this issue to formalize my proposition that the approach followed in #18780 should be temporary, merely a mean to facilitate a transition, but that the filters introduced there should ultimately be removed once #18782 is finalized.
Hmm I guess warnings from oldestdeps are warnings from the past that we have handled one way or another. I am open to injecting -p no:warnings for that job.
Activity
oldestdeps#18782pllim commentedon Nov 10, 2025
Hmm I guess warnings from oldestdeps are warnings from the past that we have handled one way or another. I am open to injecting
-p no:warningsfor that job.neutrinoceros commentedon Jan 20, 2026
I forgot to link the PR, but this issue was already dealt with in #19000