Re: [PATCH v3 1/1] test: provide ci_shell as a convenience wrapper

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 03.11.25 18:11, 'Cedric Hombourger' via isar-users wrote:
> Ease use of the container environment that may be used to run
> tests from this project by adding a `scripts/ci_shell` script
> to invoke `kas-container` for you. The script uses the existing
> kas/isar.yml kas file to use your existing checkout of the Isar
> code: this makes it easier to test your work-in-progress changes.
> 
> Lastly, `ci_setup.sh` will produce less output (e.g. when
> installing dependencies) and will print a few hints to remind
> users with useful commands.
> 
> Signed-off-by: Cedric Hombourger <cedric.hombourger@siemens.com>
> ---
>  CONTRIBUTING.md     | 52 +++++++++++----------------------------------
>  scripts/ci_setup.sh | 32 +++++++++++++++++++++++-----
>  scripts/ci_shell    | 18 ++++++++++++++++
>  3 files changed, 57 insertions(+), 45 deletions(-)
>  create mode 100755 scripts/ci_shell
> 
> diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
> index 07621232..6970477b 100644
> --- a/CONTRIBUTING.md
> +++ b/CONTRIBUTING.md
> @@ -81,54 +81,26 @@ Plan merges to `master` so that both fit the two-week window; short extensions s
>       by launching CI tests scripts. The procedure is described below:
>  
>      ```
> -    git clone https://github.com/siemens/kas
> -    cat > kas.yml <<EOF
> -    header:
> -      version: 14
> -    build_system: isar
> -    defaults:
> -      repos:
> -        patches:
> -          repo: isar
> -    repos:
> -      isar:
> -        url: "http://github.com:/ilbers/isar"
> -        branch: next
> -        layers:
> -          meta:
> -          meta-isar:
> -    EOF
> -    kas/kas-container shell --command /work/isar/scripts/ci_setup.sh kas.yml
> +    ./scripts/ci_shell
>      ```
>  
> -    In kas shell:
> +    This will spawn a shell where you may just run:
>  
>      ```
> -    cd /work/isar/testsuite
> -    avocado run citest.py -t dev --max-parallel-tasks=1
> +    trun citest.py -t dev --max-parallel-tasks=1
>      ```
>  
> -    Your git-formatpatches may be listed in the `kas.yml` file as illustrated below:
> +    Note: (`trun` is an alias for `avocado run`).
>  
> -    ```
> -    ...
> -    repos:
> -      isar:
> -        url: "http://github.com:/ilbers/isar"
> -        branch: next
> -	patches:
> -          0001:
> -            path: /work/0001-my-contribution-to-isar.patch
> -        layers:
> -          meta:
> -          meta-isar:
> -    ```
> -
> -    Perform the above steps from a clean directory for your CI run to be as close as
> -    possible to the environment that our project maintainers will be using. That
> -    directory would contain: *.patch isar/ kas/ kas.yml
> +    The container has `/work` bind-mounted to your local copy of the Isar code
> +    base (and therefore with your changes). Make sure to track upstream changes
> +    and regularly rebase your tree: your patches shall be sent against the latest
> +    HEAD available when submitting. Keep an eye on changes while your series are
> +    under review: you may need to send a refreshed version if contributions from
> +    others were accepted and touch the same areas (make sure to re-run the test
> +    suite after rebasing).
>  
> -    Be also mindful of community-provided resources such as deb.debian.org or
> +    Be mindful of community-provided resources such as deb.debian.org or
>      snapshot.debian.org and consider using a caching proxy in your setup to
>      reduce traffic as much as possible.
>  
> diff --git a/scripts/ci_setup.sh b/scripts/ci_setup.sh
> index f373d1c0..03cf3452 100755
> --- a/scripts/ci_setup.sh
> +++ b/scripts/ci_setup.sh
> @@ -9,24 +9,46 @@ gpg_key=/etc/apt/trusted.gpg.d/debian-isar.gpg
>  [ -f "${gpg_key}" ] || {
>      wget -q http://deb.isar-build.org/debian-isar.key -O- \
>      | gpg --dearmor \
> -    | sudo dd of="${gpg_key}"
> +    | sudo dd of="${gpg_key}" status=none
>  }
>  
>  list=/etc/apt/sources.list.d/10-isar_build.list
>  [ -f "${list}" ] || {
>      echo "deb [signed-by=/etc/apt/trusted.gpg.d/debian-isar.gpg] \
>          http://deb.isar-build.org/debian-isar bookworm-isar main" \
> -    | sudo tee /etc/apt/sources.list.d/10-isar_build.list
> +    | sudo tee /etc/apt/sources.list.d/10-isar_build.list >/dev/null
>  }
>  
> +echo "🔍 Checking dependencies..."
>  tools="avocado qemu-system-aarch64 qemu-system-arm qemu-system-i386 qemu-system-x86_64"
>  need_install=0
>  for tool in ${tools}; do
>      which "${tool}" || need_install=1
>  done
>  [ "${need_install}" = "0" ] || {
> -    sudo apt-get update
> -    sudo apt-get install -y avocado qemu-system-arm qemu-system-x86
> +    echo "⏳ Installing missing dependencies..."
> +    (
> +        sudo apt-get update
> +        sudo apt-get install -y avocado qemu-system-arm qemu-system-x86
> +    ) >/dev/null
>  }
>  
> -exec /container-entrypoint ${*}
> +(
> +    cat <<'    EOF'
> +    alias tlist="avocado list"
> +    alias trun="avocado run"
> +    cd /work/testsuite
> +    EOF
> +) | sudo tee -a /etc/profile.d/ci.sh >/dev/null
> +
> +cat <<'EOF'
> +
> +💡 Use "tlist citest.py" to list existing test cases
> +💡 Use "trun citest.py:TestClass.test_method" to run a specific test
> +💡 Use "trun -p sstate=1 citest.py" to enable sstate
> +
> +✅ Test environment ready for use!
> +
> +EOF
> +
> +exec /container-entrypoint bash -l
> diff --git a/scripts/ci_shell b/scripts/ci_shell
> new file mode 100755
> index 00000000..9481a8ef
> --- /dev/null
> +++ b/scripts/ci_shell
> @@ -0,0 +1,18 @@
> +#!/bin/bash
> +# A simple wrapper to run a container to run CI tests
> +#
> +# Cedric Hombourger <cedric.hombourger@siemens.com>
> +# Copyright (c) Siemens AG, 2025
> +# SPDX-License-Identifier: MIT
> +
> +self=${0}
> +topdir=$(readlink -f $(dirname ${self})/..)
> +
> +export KAS_BUILD_DIR=$(mktemp -d)
> +cleanup() {
> +    rm -rf --one-file-system ${KAS_BUILD_DIR}
> +}
> +trap "cleanup" EXIT
> +
> +cd ${topdir}
> +kas/kas-container shell --command /work/scripts/ci_setup.sh kas/isar.yml

It's isar.yaml by now - do you plan to update this patch?

I'm still convinced we need this as workaround while we do not have
pre-packaged test framework or test container. I would would even go
further and think about forwarding parameters into the shell so that one
could directly kick off a specific test.

Also way more handy would be if the testsuite could be temporarily
parameterized to reduce larger test cases to a setup which still
triggers the issue, just faster. This would allow to share the
reproduction setup with patch contributor via a single line:

call_avocado testname --test-parameters

Testing must be thought more from the contributor perspective, less the
(existing) infrastructure.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/01d937a1-5778-4470-9d6a-2706cf8fd47c%40siemens.com.