samueldr / github-to-irc

Hi! 👋

I am working on Mobile NixOS.

Development happens at NixOS/mobile-nixos.

I am also a maintainer and a committer of Nixpkgs.

Don’t forget to checkout the NixOS homepage if you don’t know what it is!

github-to-irc's Issues

Reduce overall spammage, both from productive individual, and from productive groups

This may need #3 to be done so that messages count is already reduced

---

[08:06:16] <samueldr> uhm, so I can assume that nix and nixos not being reported by {^_^} is by design?
[08:06:46] <gchristensen> no
[08:06:58] <LnL> I think gchristensen disabled it because somebody was being too productive :)
[08:07:01] <gchristensen> yeah
[08:07:09] <samueldr> ah, so yeah, by design :)
[08:07:19] <gchristensen> well I disabled the whole thing
[08:07:27] <gchristensen> and forgot to turn it on
[08:07:32] <samueldr> good, I was wondering if I did something wrong
[08:07:54] <gchristensen> ah:)
[08:08:05] <samueldr> do you remember the productive someone, and how it caused issue, maybe it's possible to do something with heuristics?
[08:08:18] <gchristensen> joachifm merged 25 PRs
[08:09:13] <samueldr> maybe coalescing events per-user in a pre-determined timespan could help
[08:09:34] <samueldr> e.g. wait 1 or 2 minutes before sending events, and over X events, create a markdown gist listing them?
[08:09:50] <gchristensen> or maybe calculate the rate of messages you're wanting to send, and if over Nps don't send them?
[08:10:06] <samueldr> also
[08:10:14] <gchristensen> Npm* probably better
[08:10:48] <gchristensen> lol
[08:10:49] <samueldr> it could probably be both, chances are "spam" will be one productive individual, well, up to now it is
[08:10:51] <gchristensen> except to #nixos-bots... :P
[08:11:25] <samueldr> but in the event a sprint is occuring, it would be great to reduce spam and limit messages
[08:11:31] <gchristensen> agreed
[08:11:37] <gchristensen> however that is done would be great

https://logs.nix.samueldr.com/nixos-bots/2018-03-14#1521055382-1521056254;

PR author is used instead of who closed it

Don't wrap links with git.io

As asked:

• https://logs.nix.samueldr.com/nixos/2021-01-01#4421918;
• https://logs.nix.samueldr.com/nixos/2021-01-01#1609531792-1609532209;

Comments?

This will remove the (somewhat) unneeded indirection, at the cost of bulking-up the appearance of the messages with long links.

EDIT: There are links to commits and PRs. These are only the events from GitHub.

(scratch PR for live-fire testing, here is some weird text: Clean up after testing #4 #6 hereisazerowidthspace:​<-didyoumissit? 👌👀👌👀👌👀👌👀👌👀 ౦ 👌 thats ✔ some 👌👌 right👌👌there👌👌👌chorus: ʳᶦᵍʰᵗ ᵗʰᵉʳᵉ) mMMMMᎷМ💯 👌👌 👌НO0ОଠOOOOOОଠଠOoooᵒᵒᵒᵒᵒᵒᵒᵒᵒ👌 👌👌 👌 💯 👌 👀 👀 👀 👌👌) → https://git.io/vxejM"]

Allow filtering out a user's events

https://logs.nix.samueldr.com/nixos/2018-06-06#1528293393-1528294678;

TLDR:

r-ryantm's events are a good chunk of the noise from the bot. Already, filtering out those open/close events would help, even if the related push isn't filtered.

That is, it should be possible to configure the filter in a way where they are still present in the nixos-bots channel.

Coalesce PR merge + push ?

The best bet would be some kind of heuristics where

When we get one of:

• a closed PR event
• a merged PR event
• A push event finishing with a Merge commit (pattern matched)

The bot could wait some time collecting relevant events (all the same listed previously) and build its own kind of pseudo-event like "CoalescedMerge" so it will spam the channel a bit less.

That list of events if not always ordered the same way.

---

For this, we need:

• To move from blocking to non-blocking subscription
• To add a kind of queue/accumulator for some event types.

Branch deletion as 0 commits push should be ignored

[20:29:01] [{^_^}] [ofborg] @grahamc pushed 0 commits to request-id: https://git.io/vx3D9
[20:30:58] <gchristensen> samueldr: ^ that is a funny message :) I deleted the branch
[20:37:04] <samueldr> tell that to git and github :) though that's a trivial one to remove

Plug-in git.io shortener

https://blog.github.com/2011-11-10-git-io-github-url-shortener/

There may be a more recent documentation.

Introduce rspec tests with timecop...

Using saved github API responses, use rspec and timecop to write tests, especially tests for #3 and #4.

Relying solely on manual testing with the rabbitmq queue is a bad idea.

Furthermore, decoupling the queue handling code from the messaging logic is a good idea.

(simply) remove the commit log from the messages

https://github.com/samueldr/github-to-irc/blob/master/lib/webhook.rb#L125

In most cases this isn't wanted, and the commits can instead be found in the links...

✔️[17:40:03] [{^_^}] [ofborg] @grahamc merged pull request #124 → Nom → https://git.io/vpXuM
✔️[17:41:10] [{^_^}] [ofborg] @grahamc pushed 5 commits to released: https://git.io/vpXuF
×[17:41:10] [{^_^}]  → d473806f by @Ekleog: Add nom dependency
×[17:41:10] [{^_^}]  → 0c1b07c3 by @Ekleog: Simplify `parse` function using `flat_map`
×[17:41:15] [{^_^}]  → 206f1556 by @Ekleog: Use nom as the comment parser

Explore providing a digest of repository events.

https://logs.nix.samueldr.com/nixos/2018-03-19#1521480582-1521480768;

[13:30:16] <manveru> can we get a channel for this bot? :)
[13:30:45] <makefu> manveru: or maybe just squash all the commit into the one with the PR being merged
[13:30:58] <gchristensen> makefu: I turned it off just now (cc samueldr) to reudec the spam
[13:31:07] <manveru> gchristensen: thx
[13:31:16] <manveru> it's nice to have it somewhere, but probably not here...
[13:31:16] <makefu> great!
[13:31:32] <makefu> but it is a nice heartbeat imho
[13:32:04] <manveru> true... i wouldn't mind if it gave like half-hourly updates of what was merged

---

Provide a digest for main channel(s), while still providing firehose events to the firehose channel.

The digest could realistically be built using a rolling window? When receiving an event, wait for the first of 15 minutes without new events or 30 minutes elapsed.