The existing behaviour isn't quite working out, we need to come back to this feature and re-think the restrictions and scope of imported layers
To expand on this: - We currently don't allow layers with the same name as imported layers, this isn't actually required, although we need to look into the implications of non-unique names properly (e.g. if you add two layers with the same name to a project does that work?) - We require a git url - if you have a layer on your filesystem does this make sense, if we support non-git checkouts we should be able to provide a local path - Each imported layer is project specific - does it need to be, should this be optional - Should we create revisions of existing layers if the layer already exists - Should the layer imported be assigned to a particular release [fido, master, dizzy..], this has an impact on the release change mechanism and the compatible layers listed in toaster.
How we design this might also be impacted by bug 6640 and bug 6701 (just so that we don't forget keeping this in mind).
It was not clear to me what "revision" means when enter layer info. For recipes this is a number. In this context it turned out to be git branch or tag.
(In reply to comment #3) > It was not clear to me what "revision" means when enter layer info. > For recipes this is a number. > In this context it turned out to be git branch or tag. Can I ask: how did you find out what revision meant? Would changing the label to "Git revision" help in any way? Do you have any suggestions for a better label?
I clicked on the "revision" tool tip and it told me exactly what revision meant. The problem was I didn't notice the tool-tip mini-icon first time round. Renaming "Revision" to "Git Revision" would be a good solution.
(In reply to comment #5) > Renaming "Revision" to "Git Revision" would be a good solution. Patch sent https://lists.yoctoproject.org/pipermail/toaster/2016-March/004007.html
This should probably include running git ls-remote <giturl> when importing a layer, which would allow us to 1) check if a git url is reachable and warn users if it isn't 2) store available branches and show them to users for selection And maybe even other tricks we haven't thought of yet. For some background on this see https://bugzilla.yoctoproject.org/show_bug.cgi?id=9200#c1 https://bugzilla.yoctoproject.org/show_bug.cgi?id=9200#c2 https://bugzilla.yoctoproject.org/show_bug.cgi?id=9200#c3
commit 97ff2c0091c654bf01bc4b0809a6a664ad6c579c Author: Michael Wood <michael.g.wood@intel.com> Date: Fri Dec 9 16:52:49 2016