This ensures that both UID and GID of the builder user inside the
container is aligned with the caller of kas-docker - or that of "docker
run" when "-e GROUP_ID=..." is specified.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This avoids
docker run ... kasproject/kas sh -c "cd /somepath; kas build ..."
and rather allows for
docker run ... --workdir=/somepath kasproject/kas build ...
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This adds a bit heuristic to the docker entrypoint in order to move our
API towards "docker run [...] kasproject/kas build kas.yml" - without
breaking existing users. And now you can also do
docker run --rm kasproject/kas --version
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
When the user restarts an already existing kas container, errors are
thrown because of existing folders or users. One example is the usage
of gitlab-ci runners.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
When we run as root on the host and want to allow the builder to do the
same, e.g. to access root-owned volumes, accept USER_ID=0 to express
this.
This allows to tell the user to call "docker run -e USER_ID=$(id -u)",
and it will always reflect the calling context's permissions into the
container.
Reported-by: Jan Christian Grünhage <jan.christian@gruenhage.xyz>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
There is a nasty problem with legacy aufs: wic tries to find out the
block size of the filesystem that holds the partition images, but aufs
does not seem to implement this properly, returning 0 at least on Debian
Jessie. That makes wic become upset and through a division-by-zero
exception soon after.
Catch this case by warning the user about the inappropriate docker
setup during container start.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Cosmetic cleanup: call the user and its home dir "builder" as it is an
active entity. This will leave yocto build results under
/builder/build/tmp/deploy/...
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
