Checkout code in a container and run tests when container is UID 1000 and Git is 1001 #205052
🏷️ Discussion TypeQuestion 💬 Feature/Topic AreaWorkflow Configuration Discussion DetailsHi All - hope folks are having a great day! I'm trying what I would have thought was a very simple job - but its beaten me for over a week, and I'm in need of sage advice. Things I've already tried are below. Here's what I am trying to do:
Here's my yaml file: Looking for a solution with bind mountsThere has to be some way to easily mount my code into the container so that its sitting there with the ownership of the I saw this, but spinning up a service container for this seems massive overkill, and very brittle. There has to be a simple way to do this. It ought to be something that his done in 5 lines every day of the week, surely. LOL. The permissions clashHere's what I know:
The container is a privately hosted container in ghcr.io owned by Epic Games - its the Unreal Engine dev container. Its big: 45GB for the slim version that I'm using, so iterating on this problem has been exhausting. It has all the tooling and compiled source code for Unreal Engine. You need to join the Unreal Github group and sign off on agreements to get access to it, so I have my credentials to access it in the Github secrets for that repo.
The SetupMy build and test scripts:
All the scripts I need to run my tests are inside that container, at paths like this: Where it all goes wrong
I have tried running the container as root, as 1000 and as 1001 ( so leaving off the options argument altogether). As 1001 - the code won't check out - there's a permission error trying for the github runner user 1001 to write into the mounted container work dir owned by 1000. As root - we get quite far. The code checks out and builds, but the tests refuse to run because the Unreal engine code is compiled with a check for root user and refuses to run as root. I have tried a dozen combinations of sudo and su to drop privileges but the Unreal engine code still detects that its root context and will not execute. Rebuilding the container - FAIL
I tried building on top of the existing container, with a Dockerfile that pulls in the original one via FROM then chowning the whole thing but it blows up from 45GB to use my whole disk before crashing with out-of-space errors. Even if those could be fixed the CI would take all week to run. I also tried building a new container by patching their container build scripts; this similarly failed because the 1000 is baked into the core of the scripts as unwritten defaults and no amount of search/replace was effective in getting a container that worked. |
Replies: 1 comment 1 reply
|
Yeah this is a super common gotcha with container jobs, not something wrong with your setup specifically. What's happening: when you leave off options, the container runs as ue4 (1000), but the workspace on the runner is owned by 1001, so checkout can't write to it. When you switch to root, checkout/build work but Unreal itself refuses to run as root — that's baked into the engine binaries, not a permissions thing you can fix from outside. The fix that's worked for others: don't try to pick one UID for the whole job. Just run the container as root, let checkout + build happen normally, and right before your test step, (chown -R 1000:1000) the workspace/engine dirs and then run the actual test command through (su ue4 -c "..."). So something like: yaml
You don't need to touch the 45GB image at all, and it skips the whole service-container detour. Should save you from another few days of rebuilds GitHub changed the runner UID on larger runners from 1000 to 1001 specifically to make it consistent with standard runners, so if you're ever testing across both runner types, don't hardcode 1001 anywhere — resolve it at runtime instead. |
Yeah this is a super common gotcha with container jobs, not something wrong with your setup specifically.
What's happening: when you leave off options, the container runs as ue4 (1000), but the workspace on the runner is owned by 1001, so checkout can't write to it. When you switch to root, checkout/build work but Unreal itself refuses to run as root — that's baked into the engine binaries, not a permissions thing you can fix from outside.
The fix that's worked for others: don't try to pick one UID for the whole job. Just run the container as root, let checkout + build happen normally, and right before your test step, (chown -R 1000:1000) the workspace/engine dirs and then run the actual …