yasrt · Dokumentation

Konfiguration und Hooks

.yasrt.yaml im Repository-Root, und das Minimum ist eine Zeile: product: image. Alles Weitere ist optional, in schema/yasrt.schema.json dokumentiert und wird von yasrt check validiert.

product leitet Nicht-Release-Pfade und Tag-Format ab: image, package, extension, custom
Organisationsdefaults liegen per --defaults unter der Datei des Repositories
Hooks rufen jedes Executable an fünf Punkten des Releases

Schema im Repository →

Die Datei

product: image    # image | package | extension | custom

product leitet die Pfade ab, die kein Release auslösen können, und das Tag-Format:

product	Nicht-Release-Pfade	Tag-Format
`image`	`CHANGELOG.md`, `README.md`, `docs/` – nicht** die CI-Datei, die baut das Image	`1.2.3`
`package`	obiges plus`.gitlab-ci.yml`, `.gitlab/`, `.github/`	`v1.2.3`
`extension`	wie `package`	`v1.2.3`
`custom`	nichts abgeleitet; `non_release_paths` ist Pflicht	`1.2.3`

Die Standardregeln sind die von semantic-release: ein Breaking Change ist ein Major, feat ein Minor, fix, perf und revert ein Patch, alles andere nichts.

Organisationsdefaults

--defaults datei (wiederholbar, oder eine :-getrennte Liste in YASRT_DEFAULTS) legt YAML-Dateien unter die des Repositories: Maps mergen, Skalare und Listen ersetzen, das Repository gewinnt. Dort gehören eine Bot-Identität, chore → patch für Dependency-Bumps oder ein Hook-Manifest als Nicht-Release-Pfad hin: einmal gesagt, im CI-Template, das jedes Repository ohnehin einbindet, statt in jedem Repository.

Hooks

Erweiterungspunkte, in der Reihenfolge, in der sie laufen. Ein Hook ist ein beliebiges Executable; er bekommt den Release-Kontext als JSON auf stdin und als RELEASE_*-Umgebungsvariablen, und meldet Fehler mit einem Exit-Code ungleich null.

hooks:
  before_tag:
    - run: ./scripts/policy-check
      name: policy gate
      timeout: 90s
  after_tag:
    - run: ./scripts/publish.sh
  after_release:
    - run: ./scripts/notify.sh
      allow_failure: true
  on_failure:
    - run: ./scripts/page-someone.sh

Ereignis	Wann	Fehler
`after_analysis`	in `next`, nach der Entscheidung	gemeldet
`before_tag`	in `release`, vor jedem Schreibzugriff	bricht ab, Repository unberührt
`after_tag`	Tag auf dem Remote, Release-Commit noch nicht gemacht	bricht ab
`after_release`	zuletzt, nach Forge-Release und Triggern	gemeldet
`on_failure`	wenn `release` gleich mit Fehler endet; bekommt `error` und `failed_step`	gemeldet

args werden wörtlich übergeben, ohne Shell, also wird nichts gesplittet oder glob-expandiert. Hooks erben die Umgebung des Jobs (ein Hook, der einen Token braucht, liest ihn dort) und bekommen nie einen im Payload; was sie ausgeben, landet im Laufbericht, Secrets maskiert.

Alles Weitere ist optional und in schema/yasrt.schema.json dokumentiert, das Editoren zur Vervollständigung nutzen und gegen das yasrt check validiert; die ganze Oberfläche steht in docs/SPEC.md §5.

yasrt entfernen

.yasrt.yaml und die CI-Jobs löschen. yasrt hält keinen eigenen Zustand: alles, was es erzeugt, ist ein Tag, ein Commit, ein Release auf der Forge und ein Job-Artefakt. Auf GitLab danach die Job-Token-Push-Einstellung abschalten, wenn nichts anderes sie braucht.

Weiter

Zurück zu yasrt

Die Übersicht: Problem, Fit-Check, drei Kommandos, alle Kapitel.

yasrt →

Forges und Signierung

GitLab, GitHub, Forgejo im Vergleich, und wie Release-Commit und Tag signiert werden.

Lesen →