[PATCH] kas-container: allow to specify repo, work and build dir used

[alexander...@siemens.com]

From: Alexander Heinisch <alexander...@siemens.com>

By default kas uses following values for:
KAS_WORK_DIR ... current working directory
KAS_BUILD_DIR ... ${KAS_WORK_DIR}/build
and kas executes in the current working directory / dir of invocation

When running ./kas-container those paths change to:
KAS_WORK_DIR ... /work
KAS_BUILD_DIR ... /build
and kas executes in /repo

This changes the used paths dependent on container or non-container
invocation of kas. While this should not matter in general, it does
when using custom `BBLAYERS` assignments (instead of kas autogenerated ones).

Signed-off-by: Alexander Heinisch <alexander...@siemens.com>
---
kas-container | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/kas-container b/kas-container
index 6000783..2db0542 100755
--- a/kas-container
+++ b/kas-container
@@ -604,25 +604,30 @@ if [ "${KAS_DOCKER_ROOTLESS}" = "1" ]; then
enable_docker_rootless
fi

+KAS_CONTAINER_REPO_DIR=${KAS_CONTAINER_REPO_DIR:-"/repo"}
+KAS_CONTAINER_WORK_DIR=${KAS_CONTAINER_WORK_DIR:-"/work"}
+KAS_CONTAINER_BUILD_DIR=${KAS_CONTAINER_BUILD_DIR:-"/build"}
+
if [ "${KAS_CMD}" = "diff" ]; then
if [ "$(echo "${KAS_FILES}" | wc -w)" -eq "2" ]; then
_KAS_REPO_DIR1="$(echo "${KAS_REPO_DIRS}" | awk '{print $1}')"
_KAS_REPO_DIR2="$(echo "${KAS_REPO_DIRS}" | awk '{print $2}')"
- _KAS_FILES1="$(echo "${KAS_FILES}" | awk '{print $1}' | sed 's|'"${_KAS_REPO_DIR1}"'/|/repo/|g')"
+ _KAS_FILES1="$(echo "${KAS_FILES}" | awk '{print $1}' | sed 's|'"${_KAS_REPO_DIR1}"'/|'"${KAS_CONTAINER_REPO_DIR}"'/|g')"
_KAS_FILES2="$(echo "${KAS_FILES}" | awk '{print $2}' | sed 's|'"${_KAS_REPO_DIR2}"'/|/repo2/|g')"
KAS_FILES="${_KAS_FILES1} ${_KAS_FILES2}"
set -- "$@" -v "${_KAS_REPO_DIR2}:/repo2:${KAS_REPO_MOUNT_OPT}"
fi
else
- KAS_FILES="$(echo "${KAS_FILES}" | sed 's|'"${KAS_REPO_DIR}"'/|/repo/|g')"
+ KAS_FILES="$(echo "${KAS_FILES}" | sed 's|'"${KAS_REPO_DIR}"'/|'"${KAS_CONTAINER_REPO_DIR}"'/|g')"
fi
-set -- "$@" -v "${KAS_REPO_DIR}:/repo:${KAS_REPO_MOUNT_OPT}" \
- -v "${KAS_WORK_DIR}":/work:rw -e KAS_WORK_DIR=/work \
- --workdir=/repo \
+
+set -- "$@" -v "${KAS_REPO_DIR}":"${KAS_CONTAINER_REPO_DIR}":"${KAS_REPO_MOUNT_OPT}" \
+ -v "${KAS_WORK_DIR}":"${KAS_CONTAINER_WORK_DIR}":rw -e KAS_WORK_DIR="${KAS_CONTAINER_WORK_DIR}" \
+ --workdir="${KAS_CONTAINER_REPO_DIR}" \
-e KAS_CONTAINER_SCRIPT_VERSION="${KAS_CONTAINER_SCRIPT_VERSION}" \
-e USER_ID="$(id -u)" -e GROUP_ID="$(id -g)" --rm --init

-forward_dir KAS_BUILD_DIR "/build" "rw"
+forward_dir KAS_BUILD_DIR "${KAS_CONTAINER_BUILD_DIR}" "rw"
forward_dir DL_DIR "/downloads" "rw"
forward_dir KAS_REPO_REF_DIR "/repo-ref" "rw"
forward_dir SSTATE_DIR "/sstate" "rw"
@@ -637,7 +642,7 @@ if git_com_dir=$(git -C "${KAS_REPO_DIR}" rev-parse --git-common-dir 2>/dev/null
KAS_GIT_OVERLAY_FILE=$(mktemp)
sed "s|gitdir: ${git_com_dir}/|gitdir: /repo-common/|" "${KAS_REPO_DIR}/.git" > "${KAS_GIT_OVERLAY_FILE}"
set -- "$@" -v "${git_com_dir}:/repo-common:${KAS_REPO_MOUNT_OPT}" \
- -v "${KAS_GIT_OVERLAY_FILE}:/repo/.git:ro"
+ -v "${KAS_GIT_OVERLAY_FILE}:${KAS_CONTAINER_REPO_DIR}/.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"
--
2.47.3

[Jan Kiszka]

On 12.01.26 19:35, alexander...@siemens.com wrote:
> From: Alexander Heinisch <alexander...@siemens.com>
>
> By default kas uses following values for:
> KAS_WORK_DIR ... current working directory
> KAS_BUILD_DIR ... ${KAS_WORK_DIR}/build
> and kas executes in the current working directory / dir of invocation
>
> When running ./kas-container those paths change to:
> KAS_WORK_DIR ... /work
> KAS_BUILD_DIR ... /build
> and kas executes in /repo
>
> This changes the used paths dependent on container or non-container
> invocation of kas. While this should not matter in general, it does
> when using custom `BBLAYERS` assignments (instead of kas autogenerated ones).
>

So, what exactly is the use case that works with your change, and how?
You are also not documenting the new variables - how should anyone be
able to make use of them?

Jan

Siemens AG, Foundational Technologies
Linux Expert Center

[Heinisch, Alexander]

On Wed, 2026-01-14 at 08:58 +0100, Jan Kiszka wrote:
> On 12.01.26 19:35, alexander...@siemens.com wrote:
> > From: Alexander Heinisch <alexander...@siemens.com>
> >
> > By default kas uses following values for:
> > KAS_WORK_DIR  ... current working directory
> > KAS_BUILD_DIR ... ${KAS_WORK_DIR}/build
> > and kas executes in the current working directory / dir of
> > invocation
> >
> > When running ./kas-container those paths change to:
> > KAS_WORK_DIR ... /work
> > KAS_BUILD_DIR ... /build
> > and kas executes in /repo
> >
> > This changes the used paths dependent on container or non-container
> > invocation of kas. While this should not matter in general, it does
> > when using custom `BBLAYERS` assignments (instead of kas
> > autogenerated ones).
> >
>
> So, what exactly is the use case that works with your change, and
> how?

We need to specify exact order of layers in `BBLAYERS`. 
Therefore, we use something like this in our kas file:

```
bblayers_conf_header:
layer_order_strict: |
# Order of layers needs to be pinned
# to ensure downstream config files are
# preferred over upstream provided ones
BBLAYERS = " \
${TOPDIR}/.. \
${TOPDIR}/../meta-custom-layer \
"
```

There is no issue when invoking kas directly (without using kas-
container). But, when using kas-container the paths need to be changed
to something like:


```
bblayers_conf_header:
layer_order_strict: |
# Order of layers needs to be pinned
# to ensure downstream config files are
# preferred over upstream provided ones
BBLAYERS = " \
${TOPDIR}/../repo \
${TOPDIR}/../meta-custom-layer \
"
```

Thus, without proposed patch, we have to use two separate kas files
depending on running kas directly or using kas-container.

With proposed patch, one can align the paths like:

```
KAS_CONTAINER_REPO_DIR="/repo" \
KAS_CONTAINER_WORK_DIR="/repo" \
./kas-container ...
```

so the environment wrt. `BBLAYERS` is similar to:

```
kas ...
```


When setting `KAS_BUILD_DIR` it's influence on `TOPDIR` can be fixed
using `KAS_CONTAINER_BUILD_DIR`.


Note: The given example aligns with current defaults. Probably, it's a
better idea to set `KAS_WORK_DIR` to some path different than
`KAS_REPO_DIR` (current workdir is used for both by default). But, in
general, a similar fix for `BBLAYERS` like the one shown above is
needed to align relative paths wrt. `TOPDIR` (`KAS_BUILD_DIR`).

> You are also not documenting the new variables - how should anyone be
> able to make use of them?

Will add some lines in /docs/command-line/environment-variables.inc
once discussion above has resolved.

BR Alexander

1: https://groups.google.com/g/kas-devel/c/dIZsfvee-sc/m/GCTBlTx_AAAJ

Alexander Heinisch
Siemens AG
www.siemens.com

[Heinisch, Alexander]

On Wed, 2026-01-14 at 13:19 +0000, 'Heinisch, Alexander' via kas-devel
wrote:

Sry, missed to align mount options when using same mount points...
not required, when setting paths properly (see Notes below).

> ```
> KAS_CONTAINER_REPO_DIR="/repo" \
> KAS_CONTAINER_WORK_DIR="/repo" \

+ KAS_REPO_MOUNT_OPT="rw" \

> http://www.siemens.com/

--
Alexander Heinisch
Siemens AG

http://www.siemens.com/

[Jan Kiszka]

That's just a workaround for https://github.com/siemens/kas/issues/36.
We should address the root cause, rather than adding workaround interfaces.

Jan

[MOESSBAUER, Felix]

Fully agree. The proposal in [1] should be easy to implement. I'll give
it a try.

Felix

[1] https://github.com/siemens/kas/issues/36#issuecomment-2612537945

>
> Jan
>
> --
> Siemens AG, Foundational Technologies
> Linux Expert Center

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

[Heinisch, Alexander]

On Fri, 2026-01-16 at 09:25 +0000, Moessbauer, Felix (FT RPD CED OES-

I was not aware of the discussions on the github-issue ([1]) (just
searched the ML, and didn't find anything related to my issue stated in
[2])

> > .
> > We should address the root cause, rather than adding workaround
> > interfaces.

For the specific problem I described, having ordering for the layers
would fix the issue. At least, as long as all layers/repo entries in
(upstream) kas files provide propper ordering values. But that's
similar to keeping the BBFILE_PRIORITY_* aligned.
(Not an issue for me, right now, btw.)

But, following up on the discussion we had in [2], I assumed getting
the ordering of BBLAYERS fixed won't happen anytime soon!
Which at least, back then made sense, because of tricking the user to
assume a fixed order, while the ordering given in kas only impacts inc,
bbclass and conf files, but not bb or bbappend files (which comes from
BBFILE_PRIORITY_* in the respective layer.conf).

Right now, bitbake just specifies bb and bbappend order handling
explicitly (BBFILE_PRIORITY_*). For the other files there is no
official spec but the code :-) - which is only relying on search order
(BBPATH), thus, the order in which layers add their paths (BBLAYERS).

TL;DR: Having the option of specifying a fixed BBLAYERS, it's in the
users responsibility to understand that semantics instead of putting
another layer of abstraction on top, but requires the option to specify
repo- and workdir paths in kas-container.

>
> Fully agree. The proposal in [1] should be easy to implement. I'll
> give
> it a try.

Thx, for pushing [3]. Will give it a try.

BR Alexander

>

> Felix
>
> [1]
> https://github.com/siemens/kas/issues/36#issuecomment-2612537945
[2] https://groups.google.com/g/kas-devel/c/7PN5MEqDgdA/m/fnfjxxrPAgAJ
[3]
https://github.com/fmoessbauer/kas/commit/960bcd924174772d93e27454681b84e643c2e5a2

>
>
> >
> > Jan
> >
> > --
> > Siemens AG, Foundational Technologies
> > Linux Expert Center

--

[Heinisch, Alexander]

On Mon, 2026-01-19 at 10:21 +0000, 'Heinisch, Alexander' via kas-devel

Applied your patchset from [4] -> Works for me!

>
> BR Alexander
>
> >
>
> > Felix
> >
> > [1]
> > https://github.com/siemens/kas/issues/36#issuecomment-2612537945
> [2]
> https://groups.google.com/g/kas-devel/c/7PN5MEqDgdA/m/fnfjxxrPAgAJ
> [3]
> https://github.com/fmoessbauer/kas/commit/960bcd924174772d93e27454681b84e643c2e5a2
> >
> >

[4] https://groups.google.com/g/kas-devel/c/rf5gk4-BVw8