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

[treescript] switch from using `actions` to using `behaviors`

Offen
  • Stimmt etwas nicht?
#169 4 Kommentare 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
devops, release

Rechercherichtung

Beginne mit treescript/src/treescript/script.py in den Zeilen 57-67 und vergleiche dies mit iscript/src/iscript/script.py in den Zeilen 29-50. Erfasse die vorhandenen Kombinationen von Aktionen sowie die merge-day- und l10n-Workflows, bevor du die Verhaltensgrenzen festlegst. Erledigt bedeutet, dass treescript Verhaltensweisen mit separat testbaren unterstützten Workflows verwendet, einschließlich der beschriebenen Interaktionen von version-bump, Tagging, merge-day und l10n.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

treescript

In treescript, we currently use actions to determine what logic to run. This follows the mozharness model, and made sense when we first implemented treescript, to allow us to tag, version bump, and/or push independently or together. However, the script has grown in complexity, now supporting l10n bumping and merge day automation, and there are the following downsides to using actions:

  1. Various actions are incompatible with each other. Neither l10n bumping nor merge day were designed to work with the current tagging or version bumping logic, so there are caveats when choosing combinations of actions to run.
  2. If we make a large change or refactor to one or more of the actions, we need to test to make sure all valid combinations of actions still work. It isn't completely clear which combinations of actions are supported, and which are not.
  3. If we want to include or exclude an action in a given set of tasks, we also have to make an in-tree change, and coordinate landing. This likely means we need to run at least one full staging release to test this and (2).
  4. It's trickier making a change where an action behaves differently in a subset of cases. This likely means adding a task payload setting, and then making sure that setting is correctly set in all permutations of the gecko taskgraph.

In iscript, we use behaviors to determine what logic to run. Instead of multiple mix-and-match actions per task, there is a single behavior per task. If we need to be able to run tagging separately from version bumping, as well as together, that might mean three behaviors (tag, version_bump, version_bump_and_tag) or a single behavior with flags (version_bump_and_tag, with an empty new_version, for instance).

This doesn't seem like a big win when looking at just tagging, version bumping, and pushing. When we get to merge day automation, however, it's a huge win:

  • the merge day behavor can have all appropriate logic baked in. We can test these as appropriate.
    • we may even want to separate these into separate behaviors: merge_central_to_beta, merge_beta_to_release, merge_release_to_esr, bump_esr, bump_early_to_late_beta, bump_central. (bump_central could potentially be part of the merge_central_to_beta task if we wanted, though.) These would duplicate a lot of the same logic, but those could be factored out into simple standalone functions that they each call.
    • we will be able to test these separately, and be able to make more surgical changes if any of these behaviors need different workflows than the others.
  • we want to l10n bump after the central_to_beta behavior. This currently necessitates another task, and we have to deal with both a) removing DONTBUILD and b) adding CLOSED TREE, which is a change from the current non-merge-day behavior. We can add an l10n bump helper function call into the merge_central_to_beta behavior function, with the appropriate DONTBUILD / CLOSED TREE settings, and that problem is solved.
  • we want to version bump in the merge behavior. We can call the version bump helper function.
  • by having a single task handle all of these, rather than multiple disparate tasks, we avoid multiple pushes, and save in both CI compute time and taskgraph complexity.

Not a blocker, but I think moving from actions to behaviors will save us time and headache in the long run.

Vorherrschende Sprache
Python
Sterne
16
Forks
38
Ø Merge
13 Std. 21 Min.
Gemergte PRs (30 T.)
17

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.