Somebody did git init in the project's $HOME in May of 2017, but unfortunately they never followed that up with commits. I am going to start working on a .gitignore there to winnow things down to potentially useful code rather than any random file that has been added to the directory. I won't claim the task yet though because I'm not sure how much time I can give to this in the immediate future.

Thanks! I can try to help out later, but not sure I’ll be able to get to it this weekend (depends on how smoothly a certain MediaWiki upgrade will go ^^).

Let’s go with a standard GitLab repository, i.e. toolforge-repos/request/ as created by toolsadmin/Striker? (Or would multiple repositories under toolforge-repos/request-* make sense for anything?)

not sure I’ll be able to get to it this weekend

Not sure whether I'd be able to look at it this weekend already! As said in the other task: The most important features still work, so there's no pressure whatsoever.

Or would multiple repositories under toolforge-repos/request-* make sense for anything?

I don't have a strong opinion on that, but as there *might* be inter-dependencies between the different sub-tools (no idea, as I can't see the full code), a single repo would probably be the safer/easier option, no?

Mentioned in SAL (#wikimedia-cloud) [2026-02-06T21:00:21Z] <bd808> Added bd808 (self) as co-maintainer to simplify work on T416678

I created https://gitlab.wikimedia.org/toolforge-repos/request-legacycode as a repo we can push things into for public sharing. I think it will be simpler to make one big pile of things rather than trying to sort of what is what. There is no existing history to preserve here.

I have begun the process of placing the existing code and configuration in the tool's $HOME into git. My current approach, which I think should be viable, is to progressively git add files as I find them to be clean of secrets. Files that are runtime noise (*.err, *.out, etc) or pure secrets are being added to .gitignore as they are identified. An initial commit has been made to the local git repo with a commit message explaining that this is a point in time copy of the tool's home directory. I think we can just incrementally git commit --amend this commit until all files are tracked or excluded. Then we can figure out how to push it all up to gitlab.wikimedia.org for sharing.

tools.request@tools-bastion-14:~$ git l
* 1a48e30 Initial commit (34 minutes ago, tools.request) (HEAD -> master)
tools.request@tools-bastion-14:~$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        FNBot/
        libphutil/
        luke-bot/
        public_html/
        service.manifest

nothing added to commit but untracked files present (use "git add" to track)

• libphutil is a clone of https://secure.phabricator.com/diffusion/PHU/libphutil.git at 1dddbacbb252af5d228ba48a1e494145386aef92 (10 years old).
• luke-bot is a clone of https://rcm-2.wmflabs.org/diffusion/LUKE/luke-bot.git at b746d5f1609c1ef4c9900617f99faad9e07b2de7 (10 years old). That Cloud VPS webproxy is defunct (T389540#10777585).

@LucasWerkmeister may be faster than I am to add the remaining files if he still remembers anything about where he spotted secrets in the prior review.

Mentioned in SAL (#wikimedia-cloud) [2026-02-09T19:15:35Z] <lucaswerkmeister> Accept Tkarcher’s request to join https://gitlab.wikimedia.org/toolforge-repos/request-legacycode (T416678), role set to “Owner”

I don’t remember anything ^^ but T389540#10774116 is probably most of what I found at the time (sadly with less “methodology” than I’d like now).

There are a bunch of separate Git repositories in FNBot/ (along with more directories that aren’t Git repos and which will just go into the main request-legacycode repo):

• FNBot/review_bot/: local repo, no remotes
• FNBot/review_filter/: clone of https://gitlab.com/FNDE/review_filter.git (probably private or deleted)
• FNBot/review_lag/: local repo, no remotes
• FNBot/secWatch/: clone of https://gitlab.com/FNDE/secWatch.git (probably private or deleted)
• FNBot/secWatch_dev/: another clone of https://gitlab.com/FNDE/secWatch.git (both are on a master branch but on different commits; haven’t compared their histories yet, in part because Git’s “dubious ownership” security mitigation is annoying)
• FNBot/thx_bot/: local repo, no remotes

I suggest we make new GitLab repos for these and push the code there. (secWatch can have a single repo with two branches in it.) Though I haven’t checked these for secrets yet.

The more I learn about this project, the less I want to adopt it. 🫣

Yes, please, creating separate GitLab repos for the existing local ones sounds reasonable. Not even sure whether I want to keep all of them in the same project/tool in future.

Mentioned in SAL (#wikimedia-cloud) [2026-02-11T18:12:50Z] <bd808> Added lucaswerkmeister as co-maintainer to make working on T416678 easier

In T416678#11598772, @LucasWerkmeister wrote:

I suggest we make new GitLab repos for these and push the code there. (secWatch can have a single repo with two branches in it.) Though I haven’t checked these for secrets yet.

Additional empty repos created:

• https://gitlab.wikimedia.org/toolforge-repos/request-review_bot
• https://gitlab.wikimedia.org/toolforge-repos/request-review_filter
• https://gitlab.wikimedia.org/toolforge-repos/request-review_lag
• https://gitlab.wikimedia.org/toolforge-repos/request-secWatch
• https://gitlab.wikimedia.org/toolforge-repos/request-thx_bot

haven’t compared their histories yet, in part because Git’s “dubious ownership” security mitigation is annoying

To elaborate a bit more on this – Git is being annoying because the repos are owned by fnde rather than tools.request. I guess as part of the adoption request we should just chown them so that the new co-maintainer can actually work with the repos. (I’ll probably do that in a few days if nobody objects.)