Tags, und ein Fall, den GitHub nicht meldet

Eine Regel kann nicht nur ein Release ankündigen, sondern auch einen Tag. Diese Seite erklärt, was das heisst — und eine Situation, in der Chronik.io dir nichts sagen kann, weil es selbst nichts erfährt.

Ein Tag-Post wartet zehn Minuten

Die meisten Teams pushen einen Tag und veröffentlichen kurz darauf ein Release darauf. Beides sofort anzukündigen erzählt dieselbe Geschichte zweimal: einmal dünn, einmal vollständig — und die dünne zuerst.

Deshalb wartet eine Tag-Ankündigung etwa zehn Minuten, und wenn sie fällig wird, fragt Chronik.io nach, ob inzwischen ein Release auf diesem Tag erschienen ist. Wenn ja, entfällt der Tag-Post — der Release-Post sagt alles, was er gesagt hätte. Dein Protokoll hält fest, dass es passiert ist und warum, damit ein stiller Channel erklärbar bleibt statt rätselhaft.

Es funktioniert auch andersherum: Ein Release, das zuerst kam, unterdrückt eine Tag-Ankündigung, die ihm folgt.

Mehrere Tags in einem Push

⚠️ Gehen mehr als drei Tags in einem einzigen Push hoch, meldet GitHub keinen einzigen davon.

Das ist eine dokumentierte Eigenschaft der GitHub-Plattform und nichts, was unterwegs schiefgeht. Die Events entstehen gar nicht erst — es gibt also nichts, was Chronik.io empfangen könnte, nichts zu wiederholen und nichts, was ein späterer Durchlauf finden und nachholen könnte. Von hier aus ist der Push nicht von gar keinem Push zu unterscheiden.

Am meisten trifft es einen Release-Train: vier Repositories zu taggen oder vier Tags in einem git push --tags hochzuschieben, ist genau die Form, die das auslöst.

Was du tun kannst:

Tags in kleineren Portionen pushen. Drei oder weniger pro Push werden normal gemeldet.
Oder ein Release veröffentlichen auf den Tags, die zählen. Ein Release ist ein eigenes Event und wird immer gemeldet, egal wie viele Tags mit ihm hochgingen.

Es gibt hier nichts einzuschalten und nichts zu konfigurieren. Chronik.io zeigt diesen Hinweis in dem Moment, in dem du die Tag-Beobachtung einschaltest, statt dich ihn selbst herausfinden zu lassen.

Filtern, welche Tags einen Channel erreichen

Ein Repository, das unter mehreren Namen veröffentlicht — app-v1.2.0, api-v3.0.0 —, kann jeden davon in einen eigenen Channel schicken. Eine Regel nimmt ein Muster wie app-v* und lässt nur die passenden durch.

* ist der Platzhalter und steht für eine beliebige Folge von Zeichen. Ein ? gibt es nicht, und gross- und Kleinschreibung zählen: Ein Filter app-v* passt nicht auf APP-V1.2.0. Ein leerer Filter bedeutet alles — damit startet jede Regel.

Ein Tag, der nicht passt, wird stillschweigend übergangen: keine Nachricht, und nichts im Protokoll. Bei einem Repository mit zwei gefilterten Regeln wird jedes Release von einer der beiden übergangen — es festzuhalten würde das Protokoll mit Einträgen füllen, die „arbeitet wie eingerichtet" heissen.

Ein Tag, dessen Name ihn als Vorabversion kennzeichnet, etwa 7.3.0-alpha oder v2.0.0-rc.1, erreicht eine Regel nur, wenn Vorabversionen einschließen eingeschaltet ist — genau wie ein Release, das auf GitHub als Vorabversion markiert ist. Der Post sagt dann, dass es eine Vorabversion ist. Welche Namen zählen, steht auf der Seite über Vorabversionen.

Ein Repository, das Tags und keine Releases veröffentlicht — manche Projekte legen auf GitHub nie ein Release an —, kündigt seine Versionen als Tags an. Wählst du so ein Repository für eine neue Regel, ist Gepushte Tags schon eingeschaltet, und die Liste der beobachteten Repositories kennzeichnet es mit Nur Tags. Beobachtet deine Regel darauf nur Releases, sagt die Liste das, denn so eine Regel würde nie posten.

Tags auslassen. Ein zweites Feld, Außer Tags, die passen auf, nimmt Muster, auf die ein Tag nicht passen darf, in derselben Form: nur *, Gross- und Kleinschreibung zählen. Mehrere Muster werden durch Leerzeichen getrennt — ein Tag-Name kann nie eines enthalten. Der Filter darüber entscheidet zuerst, und die Ausnahme gewinnt: Mit eingeschaltetem Vorabversionen einschließen und *-alpha* als Ausnahme bekommt ein Channel Betas und Release Candidates, aber keine Alphas.

Eine Regel, deren Ausnahme alle Tags auslässt, die der Filter durchlässt, könnte nie etwas posten, deshalb lässt sie sich nicht speichern. Mit *-beta* in beiden Feldern, oder * als Ausnahme ohne Filter, nennt das Formular das Muster, das alles auslässt. Der Filter selbst nimmt genau ein Muster: Mit einem Leerzeichen darin wird er abgelehnt, weil kein Tag-Name eines enthalten kann.

Zielt der Filter auf Vorabversionen, etwa *-beta*, während Vorabversionen einschließen aus ist, warnt dich das Formular. Diese Tags bleiben aus dem Channel draußen, bis du die Option einschaltest.

Ein Muster vor dem Speichern prüfen. Unter den Feldern listet das Formular die letzten Releases und Tags des Repositorys und markiert jedes, das die Regel ankündigen würde. Bei den anderen nennt es den ersten Grund, etwa ein Muster, das nicht passt, oder ausgeschaltete Vorabversionen, und die Markierung folgt dem Formular, während du tippst. Folgen die Namen einem Schema, etwa Datumsangaben wie 2026.09.24.1, Versionen wie v0.3.0 oder ein Paket-Präfix wie api-v1.2.0, schlägt das Formular ein Muster dafür vor und nennt, auf wie viele der Namen es passt. Ein Klick setzt es in Nur Tags, die passen auf. Die Liste erscheint, sobald du Letzte Releases und Tags zeigen wählst, und erst dann werden die Tags bei GitHub gelesen. Klappt das nicht, zeigt die Liste die Releases und sagt es dazu.

Auf einem Repository, das du nur beobachtest — abonniert, ohne die App zu installieren —, liest Chronik.io die Tag-Liste stündlich, sobald eine Regel darauf Tags beobachtet. Commits werden für so ein Repository gar nicht gemeldet, deshalb wird Commits, die auf einen Branch gepusht werden dort nicht angeboten.