search

siemens / kas

Setup tool for bitbake based projects
MIT License
353 stars 144 forks source link

Command line includes don't work when coming from a git submodule #59

Open riuriuriu opened 3 years ago

riuriuriu commented 3 years ago

Running:

kas build myboard.yml:mysubmodule/mirrors.yml

Results in error:

ERROR    - All concatenated config files must belong to the same repository or all must be outside of versioning control

The file mysubmodule/mirrors.yml truly isn't from the same Repo but also isn't handled by KAS. It is just a git submodule and is nowhere mentioned in myboard.yml. Shouldn't KAS allow to use it?

The use case is that we have shared KAS include files which set common source mirrors, sstate-cache, build server options and others. And it would be nice to be able to set them on the command line to be able to choose certain configs dynamically.

The ideal way would be to have KAS check out the git repo with common kas files and still be able to reference them from the command line. But the documentation says that's prohibited. My current work-around is to share them with a git submodule which isn't handled by KAS. But as mentioned above, KAS refuses to include files from it which is really strange.

jan-kiszka commented 3 years ago

The command line include mechanism is not able to handle files from repos referenced in the main config file. There is e.g. no syntax to express that. But as you may have another repo already lying around, checked out on a previous run, referencing an include from there could work by chance - but not on clean rebuilds. That's why we check for such cases and prevent surprises.

Now, having the includes in a git submodule of the top-level repo would practically work (if you tell your users to perform a submodule checkout as well). If you can find a way to detect that case, we can relax the check.

jan-kiszka commented 2 years ago

Still relevant?

fmoessbauer commented 1 year ago

Just found this issue by accident. We internally have basically the same use-case with a kas library (to share common config and extension points like sstate, mirrors, etc...) . The current workaround is to first checkout with kas, then manually copy the shared config into the top repo and then include via the CLI.

@riuriuriu Maybe you should get involved in the discussion about the conditional includes. This solves part of it by introducing a new mechanism to handle includes based on environment variables. And it also works cross-repo in a single kas invocation.