[PATCH] kas-container: replace /work with ${KAS_WORK_DIR}

[Anakin Childerhose]

Currently, the paths inside the container are hardcoded to mount
${KAS_WORK_DIR} to /work inside the container. This causes every path
printed inside the container to be an invalid path on the host.

Mounting ${KAS_WORK_DIR} as ${KAS_WORK_DIR} instead makes the paths
inside the container match the paths outside the container.

Having the paths be invalid can be inconvenient for a couple reasons:
- working in a git repo in the build folder from the host environment
causes git to complain about the paths being different and causes
other git tools like lazygit to not work at all. Forcing the developer
to interact with repos from inside the container.
- editors can not intelligently interact with the paths printed inside
the containers without workarounds to account for the difference in
paths.

Signed-off-by: Anakin Childerhose <anakin.ch...@savoirfairelinux.com>
---
kas-container | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kas-container b/kas-container
index 476724c..e25007f 100755
--- a/kas-container
+++ b/kas-container
@@ -230,7 +230,7 @@ forward_dir()
if [ "${FW_DIR_REL}" = "$_varval" ]; then
KAS_RUNTIME_ARGS="${KAS_RUNTIME_ARGS} -v ${FW_DIR_REL}:$2:$3 -e $1=$2"
else
- KAS_RUNTIME_ARGS="${KAS_RUNTIME_ARGS} -e $1=/work/${FW_DIR_REL}"
+ KAS_RUNTIME_ARGS="${KAS_RUNTIME_ARGS} -e $1=${KAS_WORK_DIR}/${FW_DIR_REL}"
fi
}

@@ -584,7 +584,7 @@ else
KAS_FILES="$(echo "${KAS_FILES}" | sed 's|'"${KAS_REPO_DIR}"'/|/repo/|g')"
fi
set -- "$@" -v "${KAS_REPO_DIR}:/repo:${KAS_REPO_MOUNT_OPT}" \
- -v "${KAS_WORK_DIR}":/work:rw -e KAS_WORK_DIR=/work \
+ -v "${KAS_WORK_DIR}":"${KAS_WORK_DIR}":rw -e KAS_WORK_DIR="${KAS_WORK_DIR}" \
--workdir=/repo \
-e KAS_CONTAINER_SCRIPT_VERSION="${KAS_CONTAINER_SCRIPT_VERSION}" \
-e USER_ID="$(id -u)" -e GROUP_ID="$(id -g)" --rm --init
@@ -606,7 +606,7 @@ if git_com_dir=$(git -C "${KAS_REPO_DIR}" rev-parse --git-common-dir 2>/dev/null
-v "${KAS_GIT_OVERLAY_FILE}:/repo/.git:ro"
# if the workdir is the same as the repo dir, it is the same shared worktree
if [ "${KAS_WORK_DIR}" = "${KAS_REPO_DIR}" ]; then
- set -- "$@" -v "${KAS_GIT_OVERLAY_FILE}:/work/.git:ro"
+ set -- "$@" -v "${KAS_GIT_OVERLAY_FILE}:${KAS_WORK_DIR}/.git:ro"
fi
fi

--
2.51.0

[Jan Kiszka]

On 12.09.25 18:23, Anakin Childerhose wrote:
> Currently, the paths inside the container are hardcoded to mount
> ${KAS_WORK_DIR} to /work inside the container. This causes every path
> printed inside the container to be an invalid path on the host.
>
> Mounting ${KAS_WORK_DIR} as ${KAS_WORK_DIR} instead makes the paths
> inside the container match the paths outside the container.
>
> Having the paths be invalid can be inconvenient for a couple reasons:
> - working in a git repo in the build folder from the host environment
> causes git to complain about the paths being different and causes
> other git tools like lazygit to not work at all. Forcing the developer
> to interact with repos from inside the container.
> - editors can not intelligently interact with the paths printed inside
> the containers without workarounds to account for the difference in
> paths.

We do this mapping on separate static paths inside the container on
purpose, not only for KAS_WORK_DIR. This avoids that a user can create
collisions between the host-side path and something already existing
inside the container. If we wanted to align paths, you would at least
have to address that topic

Besides that, the reason why such alignment was attempted so far is that
the focus of kas-container is on doing the interactive work outside the
container, mostly only building inside it.

You also missed container-entrypoint. And then you would have to address
the relationships between KAS_WORK_DIR and KAS_BUILD_DIR to remain
consistent.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[MOESSBAUER, Felix]

On Fri, 2025-09-12 at 12:23 -0400, Anakin Childerhose wrote:
> Currently, the paths inside the container are hardcoded to mount
> ${KAS_WORK_DIR} to /work inside the container. This causes every path
> printed inside the container to be an invalid path on the host.
>
> Mounting ${KAS_WORK_DIR} as ${KAS_WORK_DIR} instead makes the paths
> inside the container match the paths outside the container.

This is quite a risky thing that already has been discussed in the past
and the agreement was to not do it (e.g. due to path collision
concerns, reproducible issues).

>
> Having the paths be invalid can be inconvenient for a couple reasons:
> - working in a git repo in the build folder from the host environment
> causes git to complain about the paths being different and causes
> other git tools like lazygit to not work at all. Forcing the developer
> to interact with repos from inside the container.
> - editors can not intelligently interact with the paths printed inside
> the containers without workarounds to account for the difference in
> paths.

At least for the paths that are printed via kas, we could easily add a
search / replace to convert them on the fly. This also could be made
configurable. The paths in the logfiles would still be container
internal path, though.

Would that already help you?

Felix

>
--
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

[Anakin Childerhose]

Thank you both for your time and effort!

Kas is an incredible tool I use everyday!

> At least for the paths that are printed via kas, we could easily add a
> search / replace to convert them on the fly. This also could be made
> configurable. The paths in the logfiles would still be container
> internal path, though.

Having the paths be the same printed out by bitbake and in the logs is a highly
desired feature among my coworkers and I who use kas with other container
solutions currently to get this behaviour.

Would the Kas community be open to me coming up with a patch that would make
this a kas-container option such as --use-host-paths or --preserve-host-paths?

> You also missed container-entrypoint. And then you would have to address
> the relationships between KAS_WORK_DIR and KAS_BUILD_DIR to remain
> consistent.

Indeed, I do need to better understand how these directories could be
made consistent in both scripts.

> This is quite a risky thing that already has been discussed in the past
> and the agreement was to not do it (e.g. due to path collision
> concerns, reproducible issues).

I was unable to find the previous discussions on the mailing list regarding
this. Do you happen to know where I can find them so that I can better
understand the concerns that were raised?

Again, thank you very much for your time and effort!

Best regards,

Anakin Childerhose
Open Source Software Consultant
Savoir-faire Linux

[MOESSBAUER, Felix]

On Wed, 2025-09-24 at 14:27 -0400, Anakin Childerhose wrote:
> Thank you both for your time and effort!
>
> Kas is an incredible tool I use everyday!

Thanks!

>
> > At least for the paths that are printed via kas, we could easily add a
> > search / replace to convert them on the fly. This also could be made
> > configurable. The paths in the logfiles would still be container
> > internal path, though.
>
> Having the paths be the same printed out by bitbake and in the logs is a highly
> desired feature among my coworkers and I who use kas with other container
> solutions currently to get this behaviour.

You are mentioning the logs, but what kind of logs are you referring
to? Just search / replacing the path in the kas output is rather
trivial by adding this logic to the logging formatter. However, this
does not fix the path in the persisted bitbake logs (in
/tmp/work/.../log.foo).

>
> Would the Kas community be open to me coming up with a patch that would make
> this a kas-container option such as --use-host-paths or --preserve-host-paths?

I'm not against this - as long as this does not break other features of
the kas-container. In the end, this will always be best-effort based,
as host and container paths can collide.

>
> > You also missed container-entrypoint. And then you would have to address
> > the relationships between KAS_WORK_DIR and KAS_BUILD_DIR to remain
> > consistent.
>
> Indeed, I do need to better understand how these directories could be
> made consistent in both scripts.
>
> > This is quite a risky thing that already has been discussed in the past
> > and the agreement was to not do it (e.g. due to path collision
> > concerns, reproducible issues).
>
> I was unable to find the previous discussions on the mailing list regarding
> this. Do you happen to know where I can find them so that I can better
> understand the concerns that were raised?

Here are some pointers:

- https://groups.google.com/g/kas-devel/c/dt0rFOY4XQo/m/lgb2b6AEAQAJ
- https://github.com/siemens/kas/issues/107

Felix

>
> Again, thank you very much for your time and effort!
>
> Best regards,
>
> Anakin Childerhose
> Open Source Software Consultant
> Savoir-faire Linux
>

> --
> You received this message because you are subscribed to the Google Groups "kas-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kas-devel+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/kas-devel/1371414047.1328638.1758738430215.JavaMail.zimbra%40savoirfairelinux.com.