Volumio 3 Plugins store issues and discussion

The max size of a plugin zip is 10MB, so you need to find a way to achieve that size

  • Remove unnecessary node modules, if any
  • If impossible, store somewhere else binaries\node_modules and fetch them on plugin install

Let us know if you find some strategy

OK, done~

Question - how does it work with making fixes to plugins?

Running volumio plugin submit on volspotconnect2 gives my a 401 error…

Perhaps we should also discuss some other workflow/issues, and how it would look with this new plugin store:

– How does a non owner submit changes/improvements to a plugin?
— E.g @gvolt adopted the touch_display via a PR Rewritten touch display plugin by gvolt · Pull Request #338 · volumio/volumio-plugins · GitHub, how would this kind of thing work with the new system? A lot of plugins depend on the community to make improvements/fix things once abandoned by the original author.

– The final “single source of truth” for plugin code – as being discussed over here, and here currently there is no guarantee that code you download from the plugin-store is the same that is checked into the repo. This seems to be something manually checked by the Volumio devs, and again a possible source of oversight/human error. Also, IIRC beta channels are available immediately, making a Volumio dev scrutiny moot, for compromised/malware code.

1 Like

As a plugin developer, at present I have no idea of the review status once I have submitted a plugin and generated a pull request. If a plugin submission generated a github issue, then volumio reviewers could mark the status of the submission review in the github issue. This could also be linked to a pull request within github. It would make the whole process more transparent to everyone.

I have manually created github issues and linked them to pull requests, but it would be really nice if this was automated, initiated by the volumio plugin submit operation, ideally reporting the issue number back to console when executed.

I managed to run volumio plugin submit without errors for my plugins (while logged into MyVolumio), so I think this could be a temporary server issue.

I don’t see how requiring a MyVolumio account will reinforce a “stricter review process”.

The old way:

  1. Submit PR for plugin or update of plugin to repo
  2. 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):

  1. Run volumio plugin submit while signed in to MyVolumio
  2. Submit PR for supposedly the same code submitted in step 1
  3. Maintainer checks and matches files posted through volumio plugin submit against those in PR
  4. Maintainer merges PR and then includes plugin (or update of plugin) in the plugin store only when PR has been merged

Either way, the maintainer would have to review code submitted. Only now the maintainer would have to also match the files submitted in step (1) against those in step (2). As @ashthespy observed, this introduces a greater risk of human oversight / error.

I also doubt that after a plugin was published the first time, subsequent updates through volumio plugin submit are reviewed before being made available in the plugin store (i.e. step 4). I am saying this because I updated the YouTube2 plugin to version 0.1.7 yesterday and I can already see it in the store, but the corresponding PR was never merged even for the first submitted version (0.1.4). This is worrying indeed for reasons mentioned by @ashthespy.

Is that true? As I understood it, plugin is available right away in the beta channel after volumio plugin submit (when plugin is already in the store), and the maintainer promotes it to stable in another step?

EDIT: Clarify submit after plugin is already available

Nope, that’s just my presumption, and what should be done to ensure the integrity of submitted plugins - even those in the beta channel.

If you are submitting for the first time through volumio plugin submit, it doesn’t appear right away in the plugin store. It still has to be accepted. But after that, it seems subsequent volumio plugin submit will update the plugin right away (not entirely sure, though).

That’s not happening for me at least. So I am assuming that the first submit of a plugin has to be pushed into the store after review and only following versions get immediately and automatically into the store as beta versions.

Ah right, that confirms my observations. But this would pose a security risk, would it not? IMO, even in the beta channel, plugins should not contain malicious code that harms the unwitting user…

This is how it should work.
Thanks for the great inputs, it’s very apparent that there’s still some stuff to iron things out before release.
For example, as of now, only one author can submit a plugin (which is what ash might have encountered) we need to add a facility to have multiple authors and also multiple reviewers admin in place.
Bear with us as we process your inputs and propose an improved workflow

Possible solution: we create a github action that will promote the plugin to stable channel when the PR is accepted.
This way we have validation and automation and reduce possible human error.
This also means that plugins in alpha channel are not validated, but this should allow developers to get feedbacks from users willing to stay in alpha channel. What do you think?

So when the PR is accepted, will the reviewer actually check whether the plugin in the alpha / beta channel consists of the same files as those in the PR?

IMHO we should check for every submission if the hosted files are the same as the files on the source

I also think that plugins in the beta channel should also be checked against the PRs, but I understand that this has the potential to incur much extra work on your part…

Could we not automate that?

For example the volumio plugin submit could check the latest git commit (eg git log --name-status HEAD^…HEAD) and record the result in the submission. Then the reviewer can check that the PR includes the same commit as head

Currently, the tasks are split across two eco systems volumio plugin submit and github. This isn’t really making the process simpler (at least for me).

@patrickkfkan sums up two processes quite well in #21. I think we should take the bits of the old process that works well, and merge it into the new plugin-store workflow.

My suggestion, don’t ask the developer to run volumio plugin submit (which uploads a ready to run plugin zip to the store). Instead, you could keep things as it was previously – all the review happens directly via github, on the PR, utilising all of github’s normal code review tools.

Finally, when approved (merged), the Volumio maintainer can turn all the magic knobs to make it appear in the plugin store.

This way you again have only a single source of truth, less human errors, and a more transparent process?


Thank you for all the feedback. We see that there are things to improve on the publish procedure. Please bear in mind that changing the current procedure, while maintaining the new functionalities of the plugins store is quite complex. We are brainstorming and we will probably find a suiting solution soon. In the mean time, all suggestions are welcome. Keep them coming!

1 Like


I guess I got some issues too.
Volusonic have been merged some days ago. The plugin is visible in the store (pi) but not installable, the UI stick @10%. I tryed to download it directly with the link in the detail pan and I got

"Plugin version not found"

The plugin is not present in the store for amd64 build so I couldn’t test it.