Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[meta] refactor scripts to stop importing scriptworker, start importing scriptworker_client

Offen
  • Stimmt etwas nicht?
#171 1 Kommentar 0 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
Refactoring
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
python
Bereich
cli, tooling

Rechercherichtung

Beginne damit, die Skripte zu lokalisieren, die scriptworker importieren, und vergleiche ihre Befehlszeilen-Einstiegspunkte mit scriptworker_client. Lies die Wiki-Seite Testing iscript und deren Hinweise zu create_test_workdir für die eigenständige Ausführung. Erledigt bedeutet, dass die Skripte nicht mehr von scriptworker-Kontextobjekten abhängen und dabei die Befehlszeilen-API erhalten bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Part of the rationale of having scriptworker call a script from the commandline, rather than import a python module and call a function, was to make the script independent of scriptworker. In theory this would:

  1. let us upgrade scriptworker without affecting scripts, as long as that commandline api stayed consistent,
  2. allow us to test scripts standalone, rather than requiring the worker,
  3. allow for a mixture of languages and python versions

(3) is currently no longer an issue. We've standardized on python 3. However, we still have the option of supporting other languages, especially if some other team wants to start using scriptworkers.

(2) has been theoretical, and still has some issues with user friendliness and discoverability. The testing iscript wiki page shows it's possible to test a script without scriptworker, especially when using the create_test_workdir script from scriptworker to populate the work_dir with a known task's task.json and CoT upstreamArtifacts.

The main thing we're solving here is (1). Because many scripts import scriptworker, upgrading scriptworker may still break those scripts, even if the commandline api stays consistent. Let's import scriptworker_client instead.

Doing so isn't just a simple drop-in replacement, however. scriptworker_client removes the usage of context objects, so this may be a sizeable patch set per script. But once we do this, we'll once more be able to upgrade scriptworker without fear of breaking the script, and we will be able to make all script-related changes in this repo rather than across two repos. (And the vocal opponents to the context objects will be appeased. :)

Vorherrschende Sprache
Python
Sterne
16
Forks
38
Ø Merge
1 T. 12 Std.
Gemergte PRs (30 T.)
19

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

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 mozilla-releng/scriptworker-scripts

Alle Issues in mozilla-releng/scriptworker-scripts

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

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