Tags, and one case GitHub does not report

Tags, and one case GitHub does not report

A rule can announce a tag as well as a release. This page covers what that means, and one situation where chronik cannot tell you anything — because it is never told.

A tag post waits ten minutes

Most teams push a tag and publish a release on it moments later. Announcing both immediately tells the same story twice: once thin, once complete, and the thin one first.

So a tag announcement waits about ten minutes, and when it is due chronik asks whether a release has appeared on that tag in the meantime. If one has, the tag post is dropped — the release post says everything it would have said. Your delivery log records that it happened and why, so a quiet channel is explainable rather than mysterious.

It works in the other order too: a release that arrived first suppresses a tag announcement that follows it.

Tags in one push

⚠️ When more than three tags go up in a single push, GitHub sends no notification for any of them.

This is a documented property of the GitHub platform, not something that went wrong on the way. The events are never created, so there is nothing for chronik to receive, nothing to retry, and nothing a later sweep could find and repair. From this side the push is indistinguishable from no push at all.

It matters most for a release train: tagging four repositories, or pushing four tags to one repository in a single git push --tags, is exactly the shape that triggers it.

What to do about it:

• Push tags in smaller batches. Three or fewer per push are reported normally.
• Or publish a release on the tags that matter. A release is a separate event and is always reported, however many tags went up with it.

There is nothing to switch on here and nothing to configure. chronik shows this warning at the moment you switch tag-watching on rather than leaving you to discover it.

Filtering which tags reach a channel

A repository that releases under several names — app-v1.2.0, api-v3.0.0 — can send each to its own channel. A rule takes a pattern like app-v* and lets only the matching ones through.

* is the wildcard and stands for any run of characters. There is no ?, and matching is case-sensitive: a filter of app-v* does not match APP-V1.2.0. An empty filter means everything, which is what every rule starts with.

A tag that does not match is passed over silently — no message, and nothing in the delivery log. On a repository with two filtered rules every release is passed over by one of them, so recording it would fill the log with entries that mean "working as configured".