Usage of env variables for values in `local_conf_header`

[siredmar]

Hi! I am missing the feature to set the values of a configuration key in local_conf_header via an environment variable that is present in the host that calls kas.

A use case for this might be a version string or a pre-provision token that might change for different kas builds where the only difference might be a single value.

[jan-kiszka]

Have a look at https://kas.readthedocs.io/en/latest/userguide.html#configuration-reference, env:.

[siredmar]

Sorry, but i don't understand the comment in the documentation 100%. Can you give me a short example?

On my host running kas there is an env variable: export

$ export CUSTOM_VAR=my-custom-value
$ echo ${CUSTOM_VAR}
my-custom-value
$ kas shell /path/to/kasfile.yaml

I want to The snippet of the kasfile looks like this

...
local_conf_header:
  src/meta-custom: |
    CUSTOM_VAR_FOR_YOCTO ?= <what should i enter here to get to the value of ${CUSTOM_VAR}>

[jan-kiszka]

You would do

env:
  CUSTOM_VAR: "default value"

and will be able to use ${CUSTOM_VAR} throughout your recipes and conf files, including that local_conf_header if you like to.

[siredmar]

Two questions:

1. can i override the value for CUSTOM_VAR by exporting it in the shell before running kas?
2. the kas file snippet should look like this, is that correct?

   
   env:
   CUSTOM_VAR: "default value"

local_conf_header: src/meta-custom: | CUSTOM_VAR_FOR_YOCTO = "${CUSTOM_VAR}"

[jan-kiszka]

1. " These variables are made available to bitbake via BB_ENV_EXTRAWHITE and can be overwritten by the variables of the environment in which kas is started."
2. You do not need this indirection via CUSTOM_VAR_FOR_YOCTO, just use CUSTOM_VAR directly in your recipes

[siredmar]

Thanks for the superb support! :)

[fschrempf]

I'd like to restart the discussion as in my use case simply passing the variables to bitbake via env and BB_ENV_EXTRAWHITE is not enough. In my case I would really like to reference the variables in env (or even all of the environment kas was started in) in the configuration files.

I'd like to use this to create one configuration file per OE base release/series with refspecs and another generic configuration file head.yml to override the refspecs to the branch heads. See example below.

@jan-kiszka Do you think this could be solved by adding support for referencing env variables in config files?

1. Setting refspecs according to OE base series:

kirkstone.yml

env:
  BASE_SERIES: kirkstone

repos:
  poky:
    refspec: c4e08719a782fd4119eaf643907b80cebf57f88f
  meta-openembedded:
    refspec: 50d4a8d2a983a68383ef1ffec2c8e21adf0c1a79
  meta-qt5:
    refspec: c22b8fac9ca18687c3a163807dd74853101945a8
  meta-swupdate:
    refspec: f27a63f42d124676a07401462b1c4a64f38b768b

2. Overriding the refspecs with the selected OE base series branch head:

head.yml

repos:
  poky:
    refspec: ${BASE_SERIES}
  meta-openembedded:
    refspec: ${BASE_SERIES}
  meta-qt5:
    refspec: ${BASE_SERIES}
  meta-swupdate:
    refspec: ${BASE_SERIES}

3. Usage:

Build fixed refs: kas build kirkstone.yml or kas build dunfell.yml Build head: kas build kirkstone.yml:head.yml or kas build dunfell.yml:head.yml

[jan-kiszka]

@fschrempf This does not look like fully related to the original issue. Please create a new one or, better for all the details, a thread on the mailing list.