Re: [sr #110482] Install irker hooks in poke.git

[F. Jason Park]

Hi Luca and others,

Luca Saiu <positron@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.