I didn't realize Gerrit had actual private repositories. For whatever reason https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/TransparencyReport-private,access includes https://gerrit.wikimedia.org/r/#/admin/groups/758,members which includes "non-interactive users" (of which suchabot - the account wikibugs uses - is a member).

I would much prefer if this could be handled at the Gerrit ACL level instead of depending upon wikibugs to filter out private info (at which point the private info has already made it into Toolforge)

In T185970#3929973, @Legoktm wrote:

I didn't realize Gerrit had actual private repositories. For whatever reason https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/TransparencyReport-private,access includes https://gerrit.wikimedia.org/r/#/admin/groups/758,members which includes "non-interactive users" (of which suchabot - the account wikibugs uses - is a member).

I would much prefer if this could be handled at the Gerrit ACL level instead of depending upon wikibugs to filter out private info (at which point the private info has already made it into Toolforge)

And people wonder why I don't like hosting private repos in Gerrit. But yes, the ACL fix should be pretty straightforward.

In T185970#3929973, @Legoktm wrote:

I would much prefer if this could be handled at the Gerrit ACL level instead of depending upon wikibugs to filter out private info (at which point the private info has already made it into Toolforge)

Also, this. Wikibugs cannot possibly know what "private" means unless it checks against the ACL which is far beyond its scope. Configuration really is the right fix here.

Please note that the user used for pulling the repo to production falls under that category too, and this change just broken the update procedure in production.

Well then the should be in the existing transparency group or we create a new group and add it to the ACL. Using "Non Interactive Users" is a mistake as this bug shows.

Added "private-static-site" to the ACL.