Closed rotemb-hailo closed 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)).
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
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.
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?
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.
Or https://github.com/siemens/meta-iot2050 for spread-out yaml files.
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