Spent some time trying to fix by moving to podman for docker image build and test, but hitting permissions issues via that route as well - I think I'm hitting a wall on how much I can achieve without talking to someone if there are any precedents for doing with kind of thing in this environment, or whether I am able to tweak the runner permissions to my advantage. @Pintoch do you have any insight as to who would be the best person to throw this question to within Wikimedia?

Update, encountered a different issue - pulling the previous credentials out was easy, but I am having trouble getting the gitlab runner to build anything due to communication issues with docker: https://gitlab.wikimedia.org/repos/wikibase-reconciliation/wikibase-reconciliation-wrapper/-/jobs/837388. I haven't worked with docker-in-docker on a kubernetes runner system before, so will investigate if I can route my way around it, or whether it depends on runner permissions, or switch to a completely different base image entirely.

Good morning @Pintoch, I'm happy to have a look at fixing this - would you be able to add me to the repo?

As discussed in channel https://phabricator.wikimedia.org/T419770 I was seeking approval to access the wikimedia gitlab specifically to contribute to the openrefine reconciliation service.

In T419770#11907593, @DaxServer wrote:

Thank you for organising the call @Pintoch Next week, I'm available over the weekend on the dates: 16, 17, 23, 24, 25 in the morning between 7:30-11:30 CEST / UTC+2 https://www.worldtimebuddy.com/?qm=1&lid=2950159,2643743,100,2147714,5856195&h=2950159&date=2026-5-16&sln=7.5-11.5&hf=1

That being said, I need to apologize again about this situation. When I archived my repository and promoted your fork instead, the move wasn't very thought-through. The reason for it was that I was tired of maintaining this repository in a personal capacity, and was sad to discover that Paul had made this fork without trying to contribute his Dockerization and documentation improvements to my repository. I should have reached out to him, asking him if he would consider making a PR for it (maybe he just wasn't so familiar with open source contributions, or didn't feel like his work was good enough to be integrated upstream). By creating this fork, Paul probably didn't have the intention to maintain this code base for the use of other institutions, nor to accept external contributions: it was probably just meant to be internal documentation about your own deployment(s) of the service. So pointing to your repository as the new official home of this project was bound to fail, in my opinion.