Open fermulator opened 3 years ago
Now I'm not sure how this happened, if it is a user change/error I did at some point, or if this is affecting everyone.
I CAN say, it is highly unlikely that I went into EVERY skill, and changed the branch to a specific target like is seen above. I DID do it for one or two skills for testing, but not all of them.
To get out of this, I did:
for file in $(ls -1); do cd $file; echo $file; git checkout master; git pull origin master; cd ..; done
, then restarted
EDIT: this might be a bad :x: idea ... after doing so mycroft stopped working
I found https://mycroft.ai/blog/skill-branching-18-02/ .. but this is super old, not sure what the current strategy is.
Hi @fermulator the mycroft skills uses branches for the different versions. typically the latest version is on the branch named the same thing as the current major version of mycroft-core. So all mycroft skills has a branch called 20.08 which is the branch latest development. while 20.02 will point to the latest commit of the skill made for the 20.2.x release of mycroft-core.
The information shown is a bit misleading...the way msm updates the skills is via git merge --ff-only SHA
, where SHA is the commit sha referred to by mycroft-skills. so the branch name is actually never changed from the one used when the skill was checked out (but newer commits are applied to it).
We should probably just have used main/master as latest/current version branch and do branches for the older mycroft-core versions and push fixes to those branches if needed (like we do now)
Checking out master on the mycroft-core skills will likely return them to a very old state
I see - indeed - not using a consistent branch and instead fast forwarding to SHA commit is definitely confusing :) Are there long term plans here to address/improve? Or will we never correct this? (the title therefore may not accurately reflect the reality)
Not sure where the discussions in regards to this issue. There has been some discussion of alternate strategies, for example moving from git to tar-balls. OVOS skill installer has some support for this.
OVOS skill manager uses tarballs and not git, any branch can be selected and an update simply replaces previous install, but we disagree with automatic skill updates, that will always require a user action
either way OSM was made due to creative differences with mycroft-core, so that will never be the solution for this issue since MSM will continue doing it's own thing and it's baked into core
there is ongoing work on a OSM skill to use it with mycroft, that will replace the official skill installer skill and require https://github.com/OpenVoiceOS/disable-msm-dummy-repo
keep in mind OSM is in alpha version, that sums up the state of things in regards to OVOS skill manager / OVOS skill installer
My thinking is that a Skill update should be able to overwrite the entire directory of that Skill, as Skill settings and Skills data are now stored elsewhere. Previously the Skill settings - settings.json
was stored in the directory of the Skill.
So at the moment, my plan was to use tarballs, and an update would simply replace the old Skill with the new one. Whether that's using OSM or updating MSM I don't know as I haven't looked into them yet. However we definitely do want automatic Skill updates, so on the surface I'd assume updating MSM.
what's the latest/greatest here I should try and check?
Hey there, we haven't done any work on the Skills management side of things. We've got some more fundamental changes to make before we get back to this sorry.
Describe the bug Mycroft installed via picroft, seems to never update/upgrade the skills that are installed (neither from default nor from user-added subsequently).
Noticed and discussed: https://chat.mycroft.ai/community/pl/khrqtqa97bdcdg3gn4513arrjo
To Reproduce Steps to reproduce the behavior:
auto_run.sh
script will run, updatingmycroft-core
Expected behavior
Log files Here's a sample from my system after a year of use
Environment (please complete the following information):
Additional context
We have a "suspicion" that this is to blame for randomly losing settings in skills (TBD)