This lets you specify the UID and GID of the git user during build.
The repository and app directories are owned by this git user.
typo
another typo
I swear the Dockerfile itself is correct I am just typoing the README
This lets you specify the UID and GID of the git user during build.
The repository and app directories are owned by this git user.
typo
another typo
I swear the Dockerfile itself is correct I am just typoing the README
This lets you specify the UID and GID of the `git` user during build.
The repository and app directories are owned by this `git` user.
typo
another typo
I swear the Dockerfile itself is correct I am just typoing the README
UID and GID arguments to Dockerfile
`UID` and `GID` args can now be set during build,
so following the example command in the README should fix
[#2](https://tangled.sh/@tangled.sh/knot-docker/issues/2)
by providing a `UID` and `GID` that exist on the host
so that the directories owned by git in the container
can be bind mounted on the host.
Sorry for the duplicate PR with #4 and changeless resubmissions lol I'm experimenting with jujutsu and stacked PRs I thought editing the description in past commits would have them show up in the PR but I guess not. I've pasted them down below for reference:
-git-dir following the instructions in knot-hosting, so this adds the /etc/ssh/sshd_config.d/authorized_keys_command.conf file to rootfs.UID and GID args can now be set during build, so following the example command in the README should fix #2 by providing a UID and GID that exist on the host so that the directories owned by git in the container
can be bind mounted on the host.What is the use case you are trying to solve with that?
Oh, I am dumb, I didn't notice the issue #2.
@ionchy.ca This looks great! Just make sure to also add the UID and GID parameters to the environment in the docker compose as well for people building with Docker Compose.
I've updated the Docker Compose file and the README but I still don't know how to debug why resubmitting the PR doesn't work so I'm just going to create a new one
Ok, new PR created at #9
I would still combine these into a single
RUNline, joined with&&. Each command in a dockerfile creates a new layer in the image, which bloats this more than necessary. More of a best-practice than an actual problem.