Closed Saiyato closed 2 years ago
@balbuze not sure if I should tag you, but I will also push this one to https://github.com/volumio/volumio-plugins-sources for Volumio 3. This one works on both Volumio 2 and 3 (and should be pretty much forward compatible).
Hello. I have no access (yet😉) to manage plugins for Volumio 3. So, I can't help to publish. You have to follow new categories and package.json requirements. There is a dev-doc repo on volumio GitHub. Please have a look.
Aye, just updated the categories and package.json. Also checked out the check list and I guess I'm good to go :smile: Just created three PR's (snapclient, snapserver and lastfm); I will continue testing the rest (and verify they're still relevant).
Did you submit the plugin from your device?
No, I saw some other PR's over at the volumio-plugin-sources repo, so I thought I'd do the same. That way I can use my own repo's, then copy to a branch in the fork, then PR from the branch.
That way I don't have to submit my credentials on a device that's not fully under my control.
Please have a look : https://developers.volumio.com/plugins/plugins-overview When you submit from your device, it uses your Myvolumio ID, so no need to enter credentials
I share @Saiyato concern, and never store my git credentials on a Volumio device. There are just to many security holes.
When you submit from your device, it uses your Myvolumio ID, so no need to enter credentials
Are you sure? According to forums
I will try this method (possibly tonight). Is there a preference to do is like this, and if so, are there objections against 'plain old' PR's? 😄 Just asking, not judging.
My preferred way of doing things is:
The benefit for me is that I'm in full control of my own repo and can allow people to test by releasing new versions for manual installation. Keeping the changes private typically resulted in lots of PM's and/or issues asking for new versions.
The reason for manually copying and PR-ing is a (false?) sense of control of what commits/versions/files are pushed to the Volumio-repo.
Again gotta agree with you - this is my way of doing things as well, I prefer to keep each plugin in it's own repo and track changes individually.
As I understood it (Quoting @patrickkfkan from over Volumio 3 Plugins store issues and discussion) this is now the preferred way
The old way:
- Submit PR for plugin or update of plugin to repo
- Maintainer reviews code, merges PR and packages plugin for inclusion in plugin store
The new way (with presumptions according to what makes sense to me):
- Run volumio plugin submit while signed in to MyVolumio
- Submit PR for supposedly the same code submitted in step 1
- Maintainer checks and matches files posted through volumio plugin submit against those in PR
- Maintainer merges PR and then includes plugin (or update of plugin) in the plugin store only when PR has been merged
Ok just did a quick test, it requires way more steps to rework plugins for me, because I typically treat my test lab as expendable (I sometimes just break stuff), I tend to re-image a few times a night just to be on the safe side and test fresh installs.
Maybe I'm doing something wrong, but I need to follow the below steps to submit plugins:
volumio@volumiotest:~/volumio-plugins-sources/lastfm$ git commit
*** Please tell me who you are.
Run
git config --global user.email "you@example.com" git config --global user.name "Your Name"
to set your account's default identity. Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'volumio@volumiotest.(none)')
You can just use bogus info there.
5. Staging + committing however is not enough, you need to push them to origin "Your repository contains changes that are not pushed to origin. Please push your changes. Use 'git push' to push all changes." This requires your credentials:
volumio@volumiotest:~/volumio-plugins-sources/lastfm$ git push Username for 'https://github.com':
To be honest, this is kind of a _thing_ for me; so here I stopped. But I presume I can submit afterwards.
Plus, almost forgot... this PR is specifically for Volumio2, the one in volumio-plugin-sources is for Volumio3. Is Volumio2 going EOS soon?
For example: when trying the above flow I noticed I could not add jessie as supported OS (should be an array, according to the json-file):
Invalid os: jessie. Valid values: "buster"
This seems to imply that Volumio2 is going EOS and setting the Volumio versions is only for 3.x versions and up.
Supply a semantic version range indicating the volumio version(s) that your plugin supports >=2.0.0
The above is accepted, how will it behave?
To be honest, this is kind of a thing for me; so here I stopped. But I presume I can submit afterwards.
I have cross posted to the forum thread collecting issues for the myVolumio plugin store..
This seems to imply that Volumio2 is going EOS and setting the Volumio versions is only for 3.x versions and up. Supply a semantic version range indicating the volumio version(s) that your plugin supports >=2.0.0 The above is accepted, how will it behave?
You don't have to do any plugin submit
for volumio 2, and it also doesn't require the changes to the package.json
with these fields. When this PR gets accepted, the plugin gets packaged and shows up in the old store.
The warnings you see are cause the plugin helper is meant strictly for v3.
Check, just ironed out the wrinkles for Volumio3 and changed the plugin category to match the one in Volumio3. Parity is now at 100%, plugin is good to go. :wink:
please for volumio 3 follow instructions here : https://community.volumio.org/t/volumio-3-plugin-migration-status/51716 Thanks! No more update from here
Refactor the entire condition block Auto-scrobble from all services and allow for blacklisting Tested on Volumio 3 (by multiple people)