Better Jucies - now with releases from GitHub Releases

[Sergei Egorov]

Hey everyone,

Remember Jucies? ( https://github.com/jucies/releases ) - experimental update center for Jenkins with releases directly from GitHub?

Today it became much better!

Starting from today, GitHub releases will be used to release your plugin. That said, no publish, no PRs to update your plugin's version. Just create a release on GitHub and it will be hooked up by Jucies in a few minutes.

For example, here is Pipeline View plugin released on Jucies:

https://github.com/jucies/releases/blob/master/plugins/pipeline-view.properties

As you can see - no version here, only repository reference, where release exists:

https://github.com/jenkinsci/pipeline-view-plugin/releases

Also, I'm happy to say that Build Graph Plugin and Build Name Setter Plugin were using Jucies to release their plugins as well. Wooo!

[Oleg Nenashev]

It becomes more and more interesting :)
I'm not sure how we can manage permissions for such kind of ecosystem, but it definitely doable from the technical PoV.

четверг, 28 апреля 2016 г., 12:44:59 UTC+2 пользователь Sergei Egorov написал:

[Sergei Egorov]

Well, if core will support "namespaces" for plugins (i.e. plugin's id is 'plugin-name' now, but it might be 'jenkinsci/plugin-name', 'bsideup/plugin-name', etc), permissions will be managed automatically by GitHub. Also, it will allow publishing forks of plugins. 

In fact, it's already possible with Jucies - one can create descriptor named like 'bsideup.plugin-name' in '/plugins' folder of Jucies, so it will not overlap with 'plugin-name'. 

Of couse, it's not the way how plugins are being managed right now in Jenkins ecosystem, but it's more closer to some other CI/CD systems, i.e. Wercker, where steps identified by github's slug (i.e. 'bsideup/my-super-step')

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ab2c7834-9de6-48cf-bcba-8e820cfa5fd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tomas Bjerre]

This is great!

I tried to come up with a solution for this myself. The plugins are (in my opinion) the only good thing about Jenkins. I would never use it if it was not for the plugins. A solution like this is needed, so that plugin developers can avoid situations like this:

https://groups.google.com/forum/#!searchin/jenkinsci-dev/git-changelog/jenkinsci-dev/Jsck8GgWwJg/GAZV8Y0-CAAJ

Competition is a good thing. But competition is not allowed among Jenkins plugins. Its very frustrating when you dont want to contribute to an existing plugin. Perhaps because of the way a problem is solved in an existing one. If you want to solve the same problem, or similar, in a different way, you will be denied. Or forced to merge you code into the existing one. Like in my case with the git-changelog-plugin. It is now causing confusion among users.

I'd like to see an independent marketplace where plugins can be published, rated and reviewed. Just like the Atlassian Marketplace works. I started working on something like that (https://github.com/tomasbjerre/jenkins-plugins/ and http://www.jenkins-plugins.com/) but have not had time to finish it.

-Tomas

[Sergei Egorov]

Hey Tomas,

I think we can collaborate on it - marketplace is something really great to have in Jucies :) 

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2b223392-b09f-4ffe-bcac-e69c666de666%40googlegroups.com.

[Daniel Beck]

> On 02.05.2016, at 15:08, Tomas Bjerre <tomas.b...@gmail.com> wrote:
>
> Competition is a good thing. But competition is not allowed among Jenkins plugins. Its very frustrating when you dont want to contribute to an existing plugin. Perhaps because of the way a problem is solved in an existing one. If you want to solve the same problem, or similar, in a different way, you will be denied.

Could you please point out to me where your request was denied? That thread looks like you lost interest shortly after agreeing to a name change (to reduce ambiguity, something in everyone's interest once bug reports start coming in): "Lets wait and see what he thinks about merging the plugins."

[Tomas Bjerre]

This is also the kind of discussions that can be avoided with an independent marketplace. Why would I, as a plugin developer, like to spend my time arguing about this? My plugin, my decisions, my maintenance problems.

To me its obviously that what my plugin did was what a git-changelog-plugin would do. What the existing plugin did was no where close to what I would expect it to do. Once way of reducing ambiguity is to not name a plugin git-changelog-plugin when it does not include such a feature. If my plugin could have had a similar name, users might find both, try them and see that mine actually does create a changelog.

I interpreted the request as denied. Just my interpretation. When I immediately changed the name according to the first response and one week later I was asked to change the name once more.

But lets not pollute this nice thread with this debate.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/lL1etDkbwvg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C99F696A-B340-44BE-A548-B92FFEC0AEA6%40beckweb.net.

[Thorsten Scherler]

Hi Tomas,

I checked your links regarding the plugins. I created a micro site based on http://updates.jenkins-ci.org/current/update-center.json you can find the source in https://github.com/scherler/jenkins-plugin-site and a demo in http://plugin-site.stax.net/ (it is still under development).

It is a simple rendering of the plugin list as taken from updates.jenkins-ci.org/current/update-center.json to make the information of plugins searchable and filterable.

It is based on a node server that processes the jsonp creates a in.memory "poor-mans" database (if you want to go so far to call it db) and then serves as REST backend e.g. http://plugin-site.stax.net/plugins or http://plugin-site.stax.net/labels. The front end is based on react.js and redux.

That would be easy adoptable to pull from different market places. I actually think even having the current plugins in a market place would allow as well features like rating, favorites, custom grouping, etc. Instead of using above jsonp source I would rather use a REST/CORS server that provides thus data.

salu2

[Tomas Bjerre]

You may participate in the discussion here:

https://github.com/jucies/releases/issues/15

--

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/lL1etDkbwvg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bd46e706-e131-4956-b42c-7e56db1234ab%40googlegroups.com.

[Arnaud Héritier]

I really love these initiatives but users are globally already complaining about having to choose amongst +1200 plugins ... 

Adding more UCs and plugins will just continue to increase this problem (even if we do our best to better reference them, give more data to select them, ... and we sale it as freedom for end-users to choose ...)

I'm really an Atlassian fan but don't compare https://marketplace.atlassian.com with our community

Jira has has 1000 plugins, Confluence 600 and Bamboo .... 200

If we open more the doors (which are already largely open) how many plugins will we have in front of users in 1 year ? They'll be used by how many users ?

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAK89W5KD_ue%2Bvfi2fWkJsbVTbxUyq0uc-LA34CLOrTdsrCeNdw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Daniel Beck]

> On 05.05.2016, at 08:52, Arnaud Héritier <aher...@gmail.com> wrote:
>
> I really love these initiatives but users are globally already complaining about having to choose amongst +1200 plugins ...

Then run a curated update site with only the best (whatever metric you like) plugins, and point users there. (And if they complain about limited selection, well, tell them they're a bunch of idiots :-) )

Or fix the experience of plugin discovery (this is already in flight in parts) -- App stores can handle way more apps than 1200.

The solution isn't saying 'no', but better presentation/filtering/searching.