search

siemens / kas

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

change default behaivor of fallback to the kas-work-dir #56

Closed rotemb-hailo closed 3 years ago

rotemb-hailo commented 3 years ago

The behavior of taking the fall-back folder from the kas configuration path provided is confusing and made me spent a lot of time debugging and trying to find out where the issue is, the assumption that I had is that the fall-back folder would be the KAS_WORK_DIR provided through the environment variable

jan-kiszka commented 3 years ago

Please see https://github.com/siemens/kas/blob/master/CONTRIBUTING.md.

But already note that your patch is incorrect, breaking existing use cases (if KAS_WORK_DIR != dirname(kasfile)).

rotemb-hailo commented 3 years ago

Please see https://github.com/siemens/kas/blob/master/CONTRIBUTING.md.

But already note that your patch is incorrect, breaking existing use cases (if KAS_WORK_DIR != dirname(kasfile)).

I wouldn't say it incorrect, back support is needed somehow, that's rights. maybe this should be an issue and not a pull request, I'm open to new ideas on how to fix this mechanism but IMO the final line is that the fallback path shouldn't be the path of the kas configuration

https://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/ take a look on meta-arm for example, the fallback shouldn't be into "kas" directory IMO

jan-kiszka commented 3 years ago

We likely lack documentation (and I'm happy to take patches improving that): The fallback case is when a repository is not under version control, thus kas cannot identify its root. In that case, we assume the root is the source directory of the kas file referring to it. KAS_WORK_DIR can be outside of the source dir, thus is never a correct fallback.

rotemb-hailo commented 3 years ago

We likely lack documentation (and I'm happy to take patches improving that): The fallback case is when a repository is not under version control, thus kas cannot identify its root. In that case, we assume the root is the source directory of the kas file referring to it. KAS_WORK_DIR can be outside of the source dir, thus is never a correct fallback.

Now I get it, I'll show you the source tree of our repo to point the issue `├── .git ├── kas │   ├── con3.yml │   ├── conf1.yml │   ├── conf2.yml │   ├── include2.yml │   └── include.yml └── meta-x-bsp └── random_bsp_stuff

On our tests we clone the repo and build it from scratch, we have a lot of kas configurations, therefore, we can't really place them in the home directory, this doesn't make a lot of sense in terms of the order.

the fallback is happening on "this-repo" repository, and we would like to control them. maybe a proper solution would be to add an external ENV variable for that purpose? KAS_FALLBACK_LOCATION?

jan-kiszka commented 3 years ago

Put at least one entry kas file into the top-level repo, and you are done. Options can remain under a kas folder. This is how we are addressing the case that users pull tarballs rather than git trees as well, see eg. https://github.com/siemens/meta-iot2000/commit/15d6e9e5f6a33b69d4f31be383af37f74699497a.

jan-kiszka commented 3 years ago

Or https://github.com/siemens/meta-iot2050 for spread-out yaml files.