We’ve had a malfunctioning StandardRB check on one of our repos for a few weeks. It would fail if the PR contained a single commit - a scenario I failed to originally test but I think I be forgiven for not doing so, strange as it is.
Anyway, I had to more or less totally rewrite the way it worked.
The check works by getting a list of added or modified files and passing that list to
standardrbfor checking. The reason for this is that we don’t want to run the check on the whole codebase at the moment due to a large number of StandardRB violations.
However, it seems that it’s surprisingly hard to get a list of files changed in a PR using existing actions - they all have problems or fail under weird conditions.
So, I rewrote it to get the list of files from the GitHub API instead after seeing someone mention they had done the same whilst Googling about for solutions.
Don’t use comments! Use code.
The current app I’m working on uses Redis PubSub in a few places, but it’s expanding to use Rails' ActionCable too - something I’ve never used. A question about our setup kicked off a brief investigation into how Redis stores the messages to be published to subscribers. My naive thought was that it would actually write the messages as keys like any other record, but no.
Redis does not queue anything on pub/sub channels. On the contrary, it tends to read the item from the publisher socket, and write the item in all the subscriber sockets, ideally in the same iteration of the event loop. Nothing is kept in Redis data structures.
I broke a fairly major thing this week by not surrounding an argument with quotes. Bad times. Lessons were learnt though - our testing process is clearly not good enough.