Skip to content

TST: stop treating warnings as errors in oldestdeps CI #18853

Closed

Description

@neutrinoceros

Requires progress on #18782

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.

Activity

  1. self-assigned this
    on Nov 8, 2025
  2. pllim commented on Nov 10, 2025

    @pllim
    Member

    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.

  3. neutrinoceros commented on Jan 20, 2026

    @neutrinoceros
    ContributorAuthor

    I forgot to link the PR, but this issue was already dealt with in #19000

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions