enforce integration of credentials plugin

[domi]

Hi,

I just realised that most of requests to host a new plugin on jenkins-ci are plugins which in some way or an other require a password or secret.
Unfortunate most of these plugins add there own fields and persist this information in there own configuration instead of integrating with the credentials plugin [1]. I strongly believe that nowadays
these passwords should not be handled by each single plugin it self anymore.
Therefore I propose to ask(/force) every new plugin which requires a secret to integrate with the credentials plugin. When I say enforce, then I mean
the people who fork the plugins should not do so before this requirement is met.

btw. we should have a checklist which talks about a minimal set of rules a new plugin should follow before we allow it to be forked. Other things I would like to see there are:
- clear documentation
- the <url>-tag in the pom.xml points to an existing page

WDYT?

/Domi

[1] https://wiki.jenkins-ci.org/display/JENKINS/Credentials+Plugin

[Daniel Beck]

On 04.03.2015, at 08:09, domi <do...@fortysix.ch> wrote:

> btw. we should have a checklist which talks about a minimal set of rules a new plugin should follow before we allow it to be forked. Other things I would like to see there are:
> - clear documentation
> - the <url>-tag in the pom.xml points to an existing page
>
> WDYT?

We talked about something similar a while back in the governance meeting (Oct 1 and 15 2014). There are numerous plugins that:

- Don't track their issues in our Jira and possibly not even in @jenkinsci
- Don't have a wiki page in our Confluence and/or don't link there (and possibly link nowhere)
- Don't host their source code and/or release tags in Jenkins SVN or the jenkinsci Github org
- Don't provide their sources or have non-public source repositories

IMO plugins that get distributed using the the Jenkins update center should do all of these or be kicked out to allow for a consistent user (and developer) experience. Basically, write whatever plugin you want, but if you want distribution to every Jenkins out of the box, you need to follow some rules. These particular rules should also be fairly easy to check for. We could also add an option to Jenkins to allow users the choice whether they want to get offered noncompliant plugins, similar to the 'experimental update center' option.

Going a step further and also requiring some best practices in the implementation could be done as well, but we need to be careful about what we want to enforce and balance necessary restrictions with giving plugin authors freedom in what and how they contribute. Then there's the problem with existing plugins that may even predate credentials -- how to treat them? Just checking on fork seems not enough to me.

Another option would be to improve plugin manager to make it more like an app store. This would allow for badges, tags, or 'list of plugins that do X', indicating plugins that adhere to certain best practices. "Designed for secured Jenkins" comes to mind as well -- some plugins have scripting options and just don't care who gets to run arbitrary code.

[Laurence Bordowitz]

+1

 Where should it be listed? The plugin's wiki page? Lack of this "badge" precludes certain plugins from being used. This will adversely affect "maintenance only" plugins, or orphaned plugins.

--
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-dev+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0F11F6CB-CFDA-42C5-B753-30CDE4C97054%40beckweb.net.

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

[Jan Ruzicka]

Great Idea,

BUT

The problem is that Jenkins community can't even keep up existing reports for plugins.

Example: Project infra_plugin_changes_report

Generating report for Unreleased Plugin Changes [1]
Last successfully updated to wiki on "Mon Mar 24 04:13:31 EDT 2014" (Nearly a year ago.)
Problem is just in the credentials for upload to wiki.

The report for example shows some plugins that have GitHub repos, but don't have the latest released versions checked in.

On the other hand there are also plugin repositories that don't have any releases.

Jan

[1] https://wiki.jenkins-ci.org/display/JENKINS/Unreleased+Plugin+Changes

> 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/0F11F6CB-CFDA-42C5-B753-30CDE4C97054%40beckweb.net.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>

> --
> 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/730039146.2803208.1425493103045.JavaMail.yahoo%40mail.yahoo.com.

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

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.