Conversation
|
Can you also make a PR to change https://github.com/JuliaRegistries/user-blocklist to reflect:
|
|
@DilumAluthge should the tests run against the actual blocklist repo? That leaks the existence of it and URL but if we just test with @DilumAluthgeBot I don't think it will leak anything. Plus this PR leaks the url and existence anyway haha. |
|
The existence of the banlist repo (and its URL) are totally fine (IMO) to be public. The only thing I want to keep private is the actual list of users that are banlisted. In theory there's a chance that a CI job would accidentally leak a username or user ID, so for the tests here, maybe we can set up a public "mock" repo just for testing? What do you think? |
|
If you're only testing against DilumAluthgeBot, that seems fine. I would just worry if e.g. the TOML parser throws an error when trying to parse the whole TOML file, or something like that - in theory that might leak other contents of the TOML file? |
|
Perhaps a second private test repo? Exercising the access to private repo using the token is important I think. |
|
Ah, yes we should exercise the "private repo" codepath. |
Just because the term "bot" can get a bit overloaded (e.g. confused with the AutoMerge checks), can you edit your PR description |
|
Hmm my token works locally for testing. @DilumAluthge does the CI / commentbot have a token with read access to the mock / real repo respectively |
…es/user-blocklist-mock-for-testing`
|
Superseded by #481 |
Heavily vibe-coded by Claude Opus 4.6, but examined line by line manually.
Intended to resolve #443 by adding a simple configurable blocklist check to both the commentbot and the webui. The blocklist is a (private) repo with a TOML file, and the commentbot will now fetch and check user IDs (not usernames) against this file. There is a configurable cache time on reloading the TOML file to avoid spamming the GitHub API and reduce latency on registration calls.
Should fail gracefully allowing all registrations through.