Plugin ratings in Jenkins 2.0
46 views
Skip to first unread message
Rafael Ribeiro Rezende
Nov 30, 2015, 7:59:17 AM11/30/15
to Jenkins Developers
I saw in this presentation that plugin ratings will be introduced in Jenkins 2.0.
So far, Jenkins relies on the content generated by the backend-update-center2, which is basically (afaik) a summary of the plugins available in a specified artifact repository. Jenkins Wiki provides further info about individual plugins, including the downloads graph that is planned to be embedded into the Plugin Manager itself...
Still, I couldn't figure out what is exactly behind those ratings. Who will be rating the plugins? Through which channel (Plugin Manager itself? Or an external website?)? How are the rates fed back into the Jenkins Update Site? Where are the kept?
--
Just to contextualize the question: my company hosts its own subset of Jenkins plugins. We are very much concerned about the reliability of the plugins we use from both internal and public repositories. It would be nice if we had some control over the ratings for our purpose, or at least to be able to implement such rating system for our own plugins.
(Not sure if I should ask in the Dev or User group. Decided to bring it here because the question is pretty much about what is happening in the background.)
So far, Jenkins relies on the content generated by the backend-update-center2, which is basically (afaik) a summary of the plugins available in a specified artifact repository. Jenkins Wiki provides further info about individual plugins, including the downloads graph that is planned to be embedded into the Plugin Manager itself...
Still, I couldn't figure out what is exactly behind those ratings. Who will be rating the plugins? Through which channel (Plugin Manager itself? Or an external website?)? How are the rates fed back into the Jenkins Update Site? Where are the kept?
--
Just to contextualize the question: my company hosts its own subset of Jenkins plugins. We are very much concerned about the reliability of the plugins we use from both internal and public repositories. It would be nice if we had some control over the ratings for our purpose, or at least to be able to implement such rating system for our own plugins.
(Not sure if I should ask in the Dev or User group. Decided to bring it here because the question is pretty much about what is happening in the background.)
R. Tyler Croy
Nov 30, 2015, 10:17:52 AM11/30/15
to jenkin...@googlegroups.com
(replies inline)
On Mon, 30 Nov 2015, Rafael Ribeiro Rezende wrote:
> I saw in this presentation <https://www.youtube.com/watch?v=9vPUMe3lzfo>
improving the plugin manager experience. The best way I can think of relating
it is that it is like a concept car. It's exploring some ideas which may or may
not make it into the production version of things :)
The ratings is one of the aspects of Gus' work that I think needs a lot more
thought spent on what ratings actually represent before it's implemented and
released..
> Still, I couldn't figure out what is exactly behind those ratings. Who will
> be rating the plugins? Through which channel (Plugin Manager itself? Or an
> external website?)? How are the rates fed back into the Jenkins Update
> Site? Where are the kept?
The update-center.json which would power the plugin manager would need some
reference to those ratings in order for the revamped plugin manager to render
them.
> --
> Just to contextualize the question: my company hosts its own subset of
> Jenkins plugins. We are very much concerned about the reliability of the
> plugins we use from both internal and public repositories. It would be nice
> if we had some control over the ratings for our purpose, or at least to be
> able to implement such rating system for our own plugins.
If you're willing to share more about how your company manages your own update
center, I'd be very interested to hear more about your approach off the list.
Cheers
- R. Tyler Croy
------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
% gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
------------------------------------------------------
On Mon, 30 Nov 2015, Rafael Ribeiro Rezende wrote:
> I saw in this presentation <https://www.youtube.com/watch?v=9vPUMe3lzfo>
> that plugin ratings will be introduced in Jenkins 2.0.
> So far, Jenkins relies on the content generated by the
> *backend-update-center2*, which is basically (afaik) a summary of the
> So far, Jenkins relies on the content generated by the
> plugins available in a specified artifact repository. Jenkins Wiki provides
> further info about individual plugins, including the downloads graph that
> is planned to be embedded into the Plugin Manager itself...
That video captures some exploratory work Gus Reiber has been doing around
> further info about individual plugins, including the downloads graph that
> is planned to be embedded into the Plugin Manager itself...
improving the plugin manager experience. The best way I can think of relating
it is that it is like a concept car. It's exploring some ideas which may or may
not make it into the production version of things :)
The ratings is one of the aspects of Gus' work that I think needs a lot more
thought spent on what ratings actually represent before it's implemented and
released..
> Still, I couldn't figure out what is exactly behind those ratings. Who will
> be rating the plugins? Through which channel (Plugin Manager itself? Or an
> external website?)? How are the rates fed back into the Jenkins Update
> Site? Where are the kept?
reference to those ratings in order for the revamped plugin manager to render
them.
> --
> Just to contextualize the question: my company hosts its own subset of
> Jenkins plugins. We are very much concerned about the reliability of the
> plugins we use from both internal and public repositories. It would be nice
> if we had some control over the ratings for our purpose, or at least to be
> able to implement such rating system for our own plugins.
center, I'd be very interested to hear more about your approach off the list.
Cheers
- R. Tyler Croy
------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
% gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
------------------------------------------------------
Rafael Ribeiro Rezende
Nov 30, 2015, 12:54:58 PM11/30/15
to Jenkins Developers
Our current configuration is very simple. We use the backend-update-center2 to generate the Update Sites .json of our own plugins and that's it. Every Jenkins instance is then configured with both public and private Update Sites. The only detail is that we use the same artifact repository for hosting our own plugins and as a proxy for the public repository. Still, separate repositories.
Next we would like to improve the overall experience with the available plugins by first pointing out their current reliability (for example with ratings) and improve the communication around each plugin across the company. For instance, my team is using a plugin X and, from the plugin information, I find out that another team far far away is also using it for a similar use case. It might not make sense in the public context, but everything that triggers this sort of communication is very welcome for exchange of experiences.
I was wondering that maybe the backend-update-center2 itself could be the focus of many improvements in this direction. I've been thinking if a General Plugin Manager would make sense as a more dynamic layer between the artifact repository and the Jenkins instances. We would like, for example, to add tags/labels to plugins, create profiles so that every internal team has a different set of plugins available, also have a per team management of which repositories to use. This General Plugin Manager would be a standalone server and very likely, in my opinion, the best place to keep dynamic information like those ratings...
Just ideas. I would like to hear some opinions...
Next we would like to improve the overall experience with the available plugins by first pointing out their current reliability (for example with ratings) and improve the communication around each plugin across the company. For instance, my team is using a plugin X and, from the plugin information, I find out that another team far far away is also using it for a similar use case. It might not make sense in the public context, but everything that triggers this sort of communication is very welcome for exchange of experiences.
I was wondering that maybe the backend-update-center2 itself could be the focus of many improvements in this direction. I've been thinking if a General Plugin Manager would make sense as a more dynamic layer between the artifact repository and the Jenkins instances. We would like, for example, to add tags/labels to plugins, create profiles so that every internal team has a different set of plugins available, also have a per team management of which repositories to use. This General Plugin Manager would be a standalone server and very likely, in my opinion, the best place to keep dynamic information like those ratings...
Just ideas. I would like to hear some opinions...
Reply all
Reply to author
Forward
0 new messages