Improving the daily stubtest check for third-party stubs

Offen
  • Stimmt etwas nicht?
#14,838 3 Kommentare 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
30/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
python
Bereich
testing-qa, tooling

Rechercherichtung

Beginne damit, die Implementierung von stubsabot und die tägliche stubtest-Prüfung zu finden, und verfolge dann, wie Paketversionen und unterstützte Bereiche ermittelt werden. Sieh dir den bestehenden Pfad zur Erstellung von Issues und die Integration von Paket-Releases an. Fertig ist die Arbeit, wenn neue Releases Prüfungen für betroffene Third-Party-Stubs auslösen und Fehler innerhalb des unterstützten Bereichs paketspezifische Issues eröffnen, ohne nächtliche Wiederholungen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

project: infrastructure

Currently, stubtest checks the stdlib and all third-party stubs daily and will create a new issue if there are discrepancies. While this is fine for the stdlib, it gets annoying for third-party stubs, and doesn't scale well. We either need to fix third-party stubs to a fixed version, which is often overly specific and causes a new stubsabot issue whenever a new micro version is released, or we need to use a range, which has the danger of triggering a new issue daily until fixed. It also means that third-party stubs get checked every night, no matter whether a new package was released or not.

Instead I suggest we extend stubsabot to run on every newly released package version. If the new release is outside the supported version range of the stubs, stubsabot will function as it does now. If the new release is within the supported version range, stubsabot will run stubtest against the new package and open an issue specific for that package if stubtest fails.

This would make fixing these issues less pressing, but also enable us to use more relaxed version ranges. Changes in the "most annoying" packages often only concern internal API and/or are backwards compatible. In the future, we might even consider opening up the ranges more, for example by using >= X.Y.Z, < (X-1) for packages following semver.

Vorherrschende Sprache
Python
Sterne
5.1k
Forks
2.1k
Ø Merge
2 T. 7 Min.
Gemergte PRs (30 T.)
116

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus python/typeshed

Alle Issues in python/typeshed

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.