Setting environment variables in project configuration

[Jesseeee]

Hi,

I was wondering if the possibility to allow setting kas env variables in project configuration can be added?

My specific use case is that we have a bunch of projects, some of which require specific containers, and it would be great if we could specify the container to use, for development as well as for reproducibility afterwards, this is one of the only things that's currently not really captured in our configuration/output and has to be manually added to know which container is needed for a specific build/project.

I was thinking of being able to specify these variables in the configuration as there might be other ones that are interesting to set fixed e.g. DL_DIR, though this is mostly convenience.

Thanks for your consideration,
Jesse

[fmoessbauer]

Hi,

setting environment variables in the project config is already supported using the env key.
However, I guess you are looking for something different: A way to express the env-vars used by kas-container (e.g. by providing an env file). This is not yet possible, but someone recently asked for a similar feature on the kas mailing list.

Can you provide a bit more details on your use-case? E.g. how your development workflow looks like?

Best regards,
Felix

[Jesseeee]

Hi,

setting environment variables in the project config is already supported using the env key. However, I guess you are looking for something different: A way to express the env-vars used by kas-container (e.g. by providing an env file). This is not yet possible, but someone recently asked for a similar feature on the kas mailing list.

Can you provide a bit more details on your use-case? E.g. how your development workflow looks like?

Best regards, Felix

Hello Felix,

Thank you for the response, my use case is two fold.
On the one hand we have our own containers (IT certificates and whatnot, extra libs e.g. for Xilinx builds) and we have to work with different versions of these, having a system where we would immediately know and use the right container would be very helpful.
Second is that once we release a software, we'd also like to keep track of how exactly it was built and in which environment, and of course a container is very good for keeping that under control, but we'd also like to keep this information somewhere as a build artifact and currently that's something we have to do on top of the kas build itself.

Being able to express such variables in the project configuration would allow us to move to being able to having all the necessary reproducibility information contained in the kas project definition itself without having to manually add things onto the build artifacts.

Best regards,
Jesse

[fmoessbauer]

On the one hand we have our own containers (IT certificates and whatnot, extra libs e.g. for Xilinx builds) and we have to work with different versions of these, having a system where we would immediately know and use the right container would be very helpful.

That means you do something like this, right?

export KAS_CONTAINER_IMAGE="special-image:4.6"
kas-container build project-config.yml

Second is that once we release a software, we'd also like to keep track of how exactly it was built and in which environment, and of course a container is very good for keeping that under control, but we'd also like to keep this information somewhere as a build artifact and currently that's something we have to do on top of the kas build itself.

Did you already look into the provenance feature? This should already provide most of the data. If you execute the build in a well-known CI system like GitLab-CI or GitHub Actions it also adds the job id. https://kas.readthedocs.io/en/latest/userguide/build-attestation.html. We could also think of providing an extension point so that the build environment can inject additional data.

Expressing the kas-container version in the project config is somehow a chicken-egg problem. In case of GitLab CI usually people do not use the kas-container script at all but just let the CI run the ghcr.io/siemens/kas:... image, so a "wrapper" would not help as the image is already chose once kas starts.

Noting what was used during build is easy with the standardized provenance information, though. Together with a flattened kas config (kas dump <my-config>) it should be pretty easy to reproduce the build.