siemens
Multi-config support needs to be documented
It looks like kas supports multi-config targets in the configuration file but this isn't covered by the documentation at all. Examples would also be helpful.
See https://github.com/siemens/kas/commit/fa1575790fa9f18d2c581c6ca005b0da689ca0d5 and https://github.com/siemens/kas/commit/230c5a9572363938ca575352da1e714a7e5fbf5e.
There was a similar thread on the ML: Someone missing a description should write some desired sentences in form of a doc patch. If I do this, it may not be clear enough.
I think the comment with Version 5 changes actually describe it : https://kas.readthedocs.io/en/latest/format-changelog.html#version-5 ... (though I did not get it at first)
Maybe copying the same sentence here: https://kas.readthedocs.io/en/latest/userguide.html#configuration-reference under the key target would be enough to document the current behavior. Would this be OK ?
That being said, there is fair point in this comment: https://github.com/siemens/kas/issues/7#issuecomment-804228818
Being a able to manually add multiconfig is important if a recipe uses that mechanism.
Maybe adding multiconfig under repos and then aggregate them in BBMULTICONFIG would do ?
I think the comment with Version 5 changes actually describe it : https://kas.readthedocs.io/en/latest/format-changelog.html#version-5 ... (though I did not get it at first)
Maybe copying the same sentence here: https://kas.readthedocs.io/en/latest/userguide.html#configuration-reference under the key
targetwould be enough to document the current behavior. Would this be OK ?
That would be fine. Feel free to make the sentence clearer to you at this chance - my attempt was apparently not perfect :wink:.
That being said, there is fair point in this comment: #7 (comment)
Being a able to manually add multiconfig is important if a recipe uses that mechanism. Maybe adding
multiconfigunderreposand then aggregate them in BBMULTICONFIG would do ?
I didn't think this through yet, specifically as I have no case around to try it out. If you have such a real-world case or (what will likely also be needed) write a test case that demonstrate the issue and the solution, we can give it a try.
I should define those explicit multiconfig nodes as "extra configs", in addition to automatically added ones from the target list. Duplicates will likely be harmless, otherwise we need to filter them out.
Another thing to consider is the question if we have per-repo multiconfig keys or rather a single one that works similar to local/bblayers_conf_header. Probably more a matter of taste, I currently see no major functional pros and cons.
Does anyone still feel like we are missing something in the documentation and want to write some sentences? Or can we close this?
