Including kas files via command line without overriding "target" // kas 3.0.2

[Kaufmann, Bjoern]

Hello,

I have the following kas file hierarchy (scroll down for more details):

build-product.yml

    => includes: common.yml

        => includes: product.yml

 

sources.yml:

    => includes: product.yml

    => includes:

           repo: s2l2

           file: sources.yml

 

product.yml:

    => includes:

           repo: s2l2

           file: s2l2-common.yml

 

The s2l2-common.yml includes the isar-siemens ebsy kas file.

 

The repos section, which includes other repos like s2l2, is only defined in the product.yml. That’s why I include the product.yml in build-product.yml (indirectly) and also in sources.yml, to make it known within the context of this file too so I can include the corresponding file from the s2l2 repo.

In build-product.yml I set my local main build target meta-coreshield-server-image.

Now I want to execute the following command: kas build build-product.yml:sources.yml , but then via the hierarchy of sources.yml the target ebsy-image-base is set and will be built.
Is there a possibility to avoid that or is there maybe some other way to dynamically include different kas files from other repositories?

How I understand the user guide and as written here the files will be included in the following order: build-product.yml  first, which defines its target, and afterwards sources.yml which then overrides the target by the one defined in the ebsy kas file. So changing the command to kas build sources.yml:build-product.yml should work, but for us this is more like a workaround because it slightly reduces the readability of our build pipeline, where this will be executed.

Note: Just including s2l2:sources.yml directly within build-product.yml is no option because we also sometimes want to include a  s2l2:binaries.yml  based on the value of an environment variable. And creating a separate kas file for each include possibility will lead to too many kas files because there is not only build-product.yml, but also build-sdk.yml, build-test.yml and so on.

 

Thanks in advance.

 

With kind regards
Bjoern Kaufmann

Siemens Mobility GmbH
SMO RI R&D SYS SEC
Ackerstr. 22
38126 Braunschweig, Germany
Mobile: +49 (152) 07340125
mailto:bjoern....@siemens.com
www.siemens.com

Siemens Mobility GmbH; Chairman of the Supervisory Board: Roland Busch; Management Board: Karl Blaim, Michael Peter; Registered office: Munich, Germany; Commercial registry Munich, HRB 237219; WEEE-Reg.-No. DE 92917817

 

Here are the relevant parts of my kas files:

build-product.yml

header:

  version: 8

  includes:

    - kas/common.yml

 

target:

  - meta-coreshield-server-image

 

common.yml:

header:

  version: 8

  includes:

      - kas/product.yml

 

product.yml

header:

  version: 10

  includes:

      - repo: s2l2

        file: kas/s2l2-common.yml

      - repo: cip-core

        file: kas/opt/efibootguard.yml

      - repo: cip-core

        file: kas/opt/swupdate.yml

 

distro: coreshield-bullseye

machine: coreshield-hp

 

repos:

  coreshield:

 

  s2l2:

    url: <some_url>

    refspec: <some_ref>

 

  cip-core:

    url: <some_url>

    refspec: <some_ref>

 

sources.yml

header:

  version: 10

  includes:

    - kas/product.yml

    - repo: s2l2

      file: sources.yml

 

[Jan Kiszka]

On 09.09.22 16:45, Kaufmann, Bjoern wrote:
> Hello,
>
> I have the following kas file hierarchy (scroll down for more details):
> build-product.yml
>     => includes: common.yml
>         => includes: product.yml
>
> sources.yml:
>     => includes: product.yml
>     => includes:
>            repo: s2l2
>            file: sources.yml
>
> product.yml:
>     => includes:
>            repo: s2l2
>            file: s2l2-common.yml
>
> The s2l2-common.yml includes the isar-siemens ebsy kas file.
>

> The repos section, which includes other repos like s2l2,is only defined

> in the product.yml. That’s why I include the product.yml in

> build-product.yml(indirectly) and also in sources.yml, to make it known

> within the context of this file too so I can include the corresponding
> file from the s2l2repo.
> In build-product.yml I set my local main build target
> meta-coreshield-server-image.
> Now I want to execute the following command:
> kas build build-product.yml:sources.yml , but then via the hierarchy of
> sources.yml the target ebsy-image-base is set and will be built.
> Is there a possibility to avoid that or is there maybe some other way to
> dynamically include different kas files from other repositories?
> How I understand the user guide and as written here

> <https://kas.readthedocs.io/en/latest/userguide.html#including-configuration-files-via-the-command-line> the files will be included in the following order: build-product.yml first, which defines its target, and afterwards sources.yml which then overrides the target by the one defined in the ebsy kas file. So changing the command to kas build sources.yml:build-product.yml should work, but for us this is more like a workaround because it slightly reduces the readability of our build pipeline, where this will be executed.
> *Note*: Just including s2l2:sources.yml directly within

> build-product.yml is no option because we also sometimes want to include
> a  s2l2:binaries.yml based on the value of an environment variable. And
> creating a separate kas file for each include possibility will lead to
> too many kas files because there is not only build-product.yml, but also
> build-sdk.yml, build-test.ymland so on.
>

You surely have a rather complex include hierarchy here, and that one is
like hitting the limits and concepts of what kas can model.
Specifically, I have the impression you are violating the basic concept
of kas includes:

base.yml:specialization.yml

That means, the specialization.yml will always amend or overwrite
configurations from the base.yml, but not the other way around. So you
need to order your includes accordingly, or you won't get the desired
results. There is not concept of priorities for entries, only the logic
that is described in the user manual as well. And that is already
sufficiently complex IMHO.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux