Hi Luca and others, Luca Saiu <posit...@gnu.org> writes:
> Is there some place where I could read about the configuration? Unfortunately, there's not much to read in the way of configuration. But here are the main factors that affect what gets emitted to a channel: - the `max-atom-items' option in the cgit instance[1] - the `--template' option to the command-line bot client[2] - the optional ?h=<ref> query string (effectively HEAD if absent) - the /remaining/path/components after /atom/ to filter by subtree If not already clear, the setup I'm proposing for #poke (at least provisionally) is based on cgit atom feeds. In practice, it currently piggybacks on a more general-purpose daemon that announces news posts from NNTP groups into IRC channels[3], but this may change. As it stands, things are currently rigged to poll your master branch's atom feed every 15 minutes and relay anything unseen into the channel. Nothing fancy, but there are a couple caveats to consider: 1. Some commits may never be announced. The value of `max-atom-items' (currently 10 and not under my control) determines the number of accessible log items for a given endpoint, meaning there's no history access or pagination, AFAIK[4]. IOW, if you push a sequence of more than 10 commits in one go (not uncommon, I'm guessing), the older ones will be blackholed, and you'll never see them in the channel. If you want every commit announced, you'll have to push them in tranches, one per polling period. As mentioned, it's currently set to 15 minutes but is tunable to whatever. 2. The templating facility is not very rich. Most of this has to do with what's provided by cgit's atom offering, whose behavior is a bit nonstandard[5]. Beyond that, the data it makes available to craft these announcements is comparably sparse when weighed against other options[6]. However, IMO, it's fine for most use cases. Anyway, most of these deficits don't have to be show stoppers. And we can try to adapt to your needs going forward[7]. For now, though, I propose we leave it running for a short spell and reconvene after the next real flurry of commit activity[8] to see if this arrangement is acceptable or if you want to try something more involved. Lastly, there are a few administrative notes worth mentioning[9], which I'll save to take up with whoever is responsible for your channel's upkeep. Thanks, J.P. Notes ~~~~~ [1] https://git.zx2c4.com/cgit/tree/cgitrc.5.txt?id=5258c297ba6fb604ae1415fbc19a3fe42457e49e#n254 [2] Currently set to something like: [master] Luca Saiu Sat, Jan 22 2022 02:33:59 +0000 http://git.savannah.gnu.org/cgit/poke.git/commit/?id=eb04bbe7 First line of the commit message | Rest of the commit message up to 300 bytes or so, if present... Feel free to change this up, however. I could explain the janky ad hoc templating situation, but it's easier if you just tell me what you'd like to see. The date featured in the current incarnation is the author date. A couple additional fields (email address and commit date, IIRC) are available as are most formatting codes. [3] Up-to-date sources are available by running the bot's `source' command. The back end is currently here: https://gitlab.com/jpneverwas/nntp-crier [4] Actually, these caveats mostly hinge on assumptions and observations that I'm currently awaiting confirmation on from the cgit folks, so take them with a grain of salt for now (and correct me, please, anyone more in the know). [5] https://git.zx2c4.com/cgit/commit/?h=ch/atom&id=f8d6f5b197e966e8d5269491c2e4e28d7c1f5328 [6] Revisions forwarded to NNTP groups (as emails) contain richer, more structured info, such as author time zone, commit type, committer name, short stat, and so forth. More powerful still are githooks because they run in-repo. However, these two approaches are more complicated because they involve coordinating with yet other parties (and in the case of githooks, doing so whenever we want to change something). [7] For example, if you don't want folks to have to click the link to get at some specific detail, like the number of files touched (for example), we could (in theory) have a web spider chase down whatever you're after and incorporate that into the IRC message. We could also just maintain a local copy of the repo to query. That said, even though additional measures are possible and alternatives to this atom setup exist, they are more complicated to get going and maintain, so I'd like to try this first if you wouldn't mind. [8] Or, to accelerate things, we could switch (or add) branches and have someone push something now to test (instead of waiting on master). [9] One thing to mention now though is that if at any point you've seen enough (even after this probationary/trial phase), please just KICK the bot (and optionally +b it) and I'll hopefully get around to killing it off before it reJOINs, which may happen if health checks fail and the supervisor restarts it.
