GitHub Organization Folder polish

[Kohsuke Kawaguchi]

I was putting together a demo site http://demo.jenkins-ci.org/ to show case Jenkins 2.0 features, during which I noticed a number of low-hanging UI improvements. 

I jotted them down under "Pipeline as Code Polish" in here.

The main idea that I want to propose here is that:

• Many of those UI improvements can be done as one time configuration of OragnizationFolder, MultiBranchProject, etc after they are created. This include icons, initial view and their columns, additional FolderProperty etc.
  
  
• Therefore we need to implement ItemListener that performs those initial configurations as soon as those Items are created into Jenkins item tree
  
  
• We should create a "GitHub Organization Folder" plugin that houses that, and this also creates a convenient aggregator for people who want to install this functionality through UC, which is another pet-peeve.

--

Kohsuke Kawaguchi

[Jesse Glick]

On Mon, Feb 29, 2016 at 8:02 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
> Many of those UI improvements can be done as one time configuration of
> OragnizationFolder, MultiBranchProject, etc after they are created. This
> include icons, initial view and their columns, additional FolderProperty
> etc.
>
> Therefore we need to implement ItemListener

No. See `MultiBranchProjectFactory.createProject` (`attributes`).

> We should create a "GitHub Organization Folder" plugin

How is this not `github-branch-source`?

> a convenient aggregator

-1 on new aggregators. A properly written setup wizard should
supersede the concept.

[Kohsuke Kawaguchi]

Hmm, there must be some disconnect here.

The whole "GitHub Organization Folder" functionality is currently divided into 3 pieces in 3 different plugins that do not depend on each other very much, which takes some time to wrap one's head around.

There's OrganizationFolder in branch-api that defines a collection of "something" as a folder (that maps to the org level folder), then there's GitHubSCMNavigator that brings in GitHub specific binding, t hen there's pipeline-multibranch that defines a collection of branches as a folder (that maps to the rep level folder.)

This split makes it unintuitive as to where the glue polish needs to go; the kind of glue that I wrote down in this, such as initial ListView set up, additional FolderProperties, etc. I was under the assumption that you want to maintain the current trinity, in which case the only place it can go would be another plugin.

But you seem to be saying that they should all go to github-branch-source. That is, that plugin will get such dependencies like pipeline-mutlibranch and branch-api. I have no problem with it, but I just want to make sure I understand you correctly.

Also, thanks for pointing out MultiBranchProjectFactory.createProject, but WorkflowMultiBranchProjectFactory.doCreateProject doesn't use it at all today, and even if that code is made to understand some attributes, one can only do what this plugin anticipates. And I still need to use something else for customizing OrganizationFolder and WorkflowJob. I think ItemListener gets the job done, but what else do you suggest?

--

Kohsuke Kawaguchi

[Jesse Glick]

On Tue, Mar 1, 2016 at 12:20 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
> I was under the assumption that you want
> to maintain the current trinity

Yes.

> in which case the only place it can go
> would be another plugin.

Well, split across the existing ones, according to API structure.

> But you seem to be saying that they should all go to github-branch-source.
> That is, that plugin will get such dependencies like pipeline-mutlibranch
> and branch-api. I have no problem with it, but I just want to make sure I
> understand you correctly.

No you did not.

> Also, thanks for pointing out MultiBranchProjectFactory.createProject, but
> WorkflowMultiBranchProjectFactory.doCreateProject doesn't use it at all
> today, and even if that code is made to understand some attributes, one can
> only do what this plugin anticipates.

Attributes for various things (folder icon, etc.) would need to be
defined in the API.

[Kohsuke Kawaguchi]

I've synced up with Jesse & Manuel offline, and now the work is in here if anyone is interested.

--
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/CANfRfr1hU3yxHK5f_jVmLo%3Dn31RuB7265Uuwf8bEc_Cqps%3D%2BCA%40mail.gmail.com.

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

--

Kohsuke Kawaguchi

[Daniel Beck]

On 05.03.2016, at 00:45, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:

> I've synced up with Jesse & Manuel offline, and now the work is in here if anyone is interested.

Correct link (not much to look at on master yet): https://github.com/jenkinsci/github-organization-folder-plugin/pull/1

[domi]

Would it be possible to generalize this GH stuff a bit more? From what I know, most git hosting services have the notion of organizations,repos,PRs... eg. GH,Bitbucket,gitlab?,gitblit?
I know GH is the most prominent, but ... yeah...
/Domi

> --
> 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/B99A9F05-F3FA-4550-88AA-069E291DA7E6%40beckweb.net.

[Manuel Jesús Recena Soto]

Hello Domi,

GitHub uses: Organization, repository, collaborator, etc..
BitBucket uses: Team, repository, groups, etc..

I'm not sure how to generalize all these services and products.

Additionally, this plugin declares a dependency with
github-branch-source. It seems clearly focused on GitHub.

Regards,

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7D293532-AB0D-4335-BC09-0E14F3093A3D%40fortysix.ch.

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

--
Manuel Recena Soto
* manuelrecena.com [/blog]
* linkedin.com/in/recena

[domi]

A team in BB is pretty much the same as an organization in GH. I know the current implementation is based in GH proprietary implementations, but I just wanted to say that this is maybe possible to generalize. E.g. The organization/team is used to distinguish and group repositories on both GH and BB, also both are part of the git repository url. Also both support PRs. So from an outside perspective I don' see why the concepts of this plugins would not work for both (independent of how the are currently implemented).
Also, think about it - at many places in IT we talk about being independent of any vendor stuff. How about being able to switch from BB to GH or anywhere else but not having to change anything in the build pipeline except the repo url?
/Domi

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CABa-Uod%2BRWb6mX6jaDTfPEts_iz07yTqB1pRNCtOH06kG%3DBQ7w%40mail.gmail.com.

[Robert Sandell]

and IIRC GitLab calls an Organisation/Team for Group and merge requests instead of pull requests, but it's still the same thing in the end.

But the terminology chosen is imho quite important, because teams adopt the terms used by their tools in everyday "shop talk". So I find that it's quite important that there are as many commonalities as possible and Jenkins should try to use the same terms as the scm it is modelling, at least in the UI, or confusion will arise.

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B8F92295-C428-4D5A-9A61-760EDF91319B%40fortysix.ch.

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

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Manuel Jesús Recena Soto]

+1 Bobby!

> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0d6BZkKmax%2Bq-yQkdhLjd-QAcyTL1OuGA2cXtL5HvxMw%40mail.gmail.com.

[domi]

I fully agree, but that in my opinion just means we need a generalisation with specific implementations for each of the supported SCM host implementations.

…and some might actually just change the labels…

The only thin I wanted to bring a cross, is that everyone is only talking about GH, but there are others on the marked too and they have the exact same concept - so if thing like this get implemented, then it would be wise to have some kind of abstraction.

my 2cents…

/Domi

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0d6BZkKmax%2Bq-yQkdhLjd-QAcyTL1OuGA2cXtL5HvxMw%40mail.gmail.com.

[Daniel Beck]

On 07.03.2016, at 14:02, domi <do...@fortysix.ch> wrote:

> it would be wise to have some kind of abstraction.

We have the Pronoun system in Jenkins for (Item, Project, Job, …), something similar here would probably take care of the UI labels.

[Jesse Glick]

On Mon, Mar 7, 2016 at 8:02 AM, domi <do...@fortysix.ch> wrote:
> …and some might actually just change the labels…

For example

https://github.com/jenkinsci/branch-api-plugin/blob/60c05e72532cd00e964090c82d01f86b977e9a33/src/main/java/jenkins/branch/MultiBranchProject.java#L618-L621

As Daniel pointed out, we have an existing `AlternativeUiTextProvider`
API, and it is not hard to imagine similar pluggability whereby an SCM
source could indicate the kind of term it prefers to be used for
various repositories or branches it produces, etc.

> if thing like this get implemented, then it would be wise
> to have some kind of abstraction.

That was the gist of my comment in the PR. That said, we need some
polish quickly for the one source which is available in an OSS plugin
today, GitHub.

[Kohsuke Kawaguchi]

Once somebody attempts to implement another one, then that effort should help drive identifying reusable pieces. I'd love to see that happen. I think Domi is probably right that there's some opportunities for more reuse, and I also agree with Bobby/Manuel that users should see the terminologies specific to their services. Fortunately, none of these code is API, so it's relatively easy to move things around later.

OTOH, it's likely that BitBucket Org Folder plugin maintainer won't care about GH Org Folder and vice versa, so if the code is separate, they will be able to make decisions on their own and innovate faster, whereas reuse would require constant collaboration which hinders velocity of development...

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7D293532-AB0D-4335-BC09-0E14F3093A3D%40fortysix.ch.

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

--

Kohsuke Kawaguchi

[Christopher Orr]

On 07/03/16 18:31, Kohsuke Kawaguchi wrote:
> Once somebody attempts to implement another one, then that effort should
> help drive identifying reusable pieces. I'd love to see that happen. I
> think Domi is probably right that there's some opportunities for more
> reuse, and I also agree with Bobby/Manuel that users should see the
> terminologies specific to their services. Fortunately, none of these
> code is API, so it's relatively easy to move things around later.
>
> OTOH, it's likely that BitBucket Org Folder plugin maintainer won't care
> about GH Org Folder and vice versa, so if the code is separate, they
> will be able to make decisions on their own and innovate faster, whereas
> reuse would require constant collaboration which hinders velocity of
> development...

You say "innovate faster", I say "create a horrible mess of inconsistent
and duplicated UIs, which is a large part of why people consider Jenkins
to be a disaster in terms of user experience".

e.g. this image shows (part of) what a user will see on the system
config page if they install the GitHub-related plugins that will be
recommended by Jenkins 2.0:
http://i.imgur.com/0Iv5lF3.png


Having had to maintain a Jenkins instance where we regularly used both
GitHub and BitBucket, I wouldn't like to imagine what the UI will look
like if more GitHub and BitBucket plugins like this get created, with
even the same or less amount of reusability than there is now.


I do think it's probably fair enough to let plugin authors do whatever
they want for many use cases, but for the really commonly used stuff —
especially SCMs — there ought to be a lot more effort put into the user
experience, rather than just the developers' experience.

Regards,
Chris


> 2016-03-05 1:07 GMT-08:00 domi <do...@fortysix.ch <mailto:do...@fortysix.ch>>:

>
> Would it be possible to generalize this GH stuff a bit more? From
> what I know, most git hosting services have the notion of
> organizations,repos,PRs... eg. GH,Bitbucket,gitlab?,gitblit?
> I know GH is the most prominent, but ... yeah...
> /Domi
>
> > Am 05.03.2016 um 01:12 schrieb Daniel Beck <m...@beckweb.net

> <mailto:m...@beckweb.net>>:

> >
> >
> >> On 05.03.2016, at 00:45, Kohsuke Kawaguchi <k...@kohsuke.org

[Kohsuke Kawaguchi]

2016-03-07 17:04 GMT-08:00 Christopher Orr <ch...@orr.me.uk>:

On 07/03/16 18:31, Kohsuke Kawaguchi wrote:

Once somebody attempts to implement another one, then that effort should
help drive identifying reusable pieces. I'd love to see that happen. I
think Domi is probably right that there's some opportunities for more
reuse, and I also agree with Bobby/Manuel that users should see the
terminologies specific to their services. Fortunately, none of these
code is API, so it's relatively easy to move things around later.

OTOH, it's likely that BitBucket Org Folder plugin maintainer won't care
about GH Org Folder and vice versa, so if the code is separate, they
will be able to make decisions on their own and innovate faster, whereas
reuse would require constant collaboration which hinders velocity of
development...

You say "innovate faster", I say "create a horrible mess of inconsistent and duplicated UIs, which is a large part of why people consider Jenkins to be a disaster in terms of user experience".

The situation you cite about GitHub below is a real one and we should fix it! In a way this is one of the motivations behind creating the recommended set of plugins, which makes us own these problems within the recommended set.

But does the same problem apply to GitHub Org Folder vs BitBucket Org Folder? Those two plugins are unlikely to share any configuration.

e.g. this image shows (part of) what a user will see on the system config page if they install the GitHub-related plugins that will be recommended by Jenkins 2.0:
http://i.imgur.com/0Iv5lF3.png


Having had to maintain a Jenkins instance where we regularly used both GitHub and BitBucket, I wouldn't like to imagine what the UI will look like if more GitHub and BitBucket plugins like this get created, with even the same or less amount of reusability than there is now.

 

I do think it's probably fair enough to let plugin authors do whatever they want for many use cases, but for the really commonly used stuff — especially SCMs — there ought to be a lot more effort put into the user experience, rather than just the developers' experience.

OK, point taken. 

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

2016-03-07 18:07 GMT-08:00 Kohsuke Kawaguchi <k...@kohsuke.org>:

e.g. this image shows (part of) what a user will see on the system config page if they install the GitHub-related plugins that will be recommended by Jenkins 2.0:
http://i.imgur.com/0Iv5lF3.png

I looked at the fresh install and GitHub Pull Request Builder isn't a part of the recommended list of plugins, so while the problem is still there, I feel a little better.

I'm still not sure where "GitHub Enterprise Servers" configuration is coming from...

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

Oh no, it's coming from GitHub Branch Source plugin!

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

Patrick told me that https://issues.jenkins-ci.org/browse/JENKINS-33228 discusses this very issue.

--

Kohsuke Kawaguchi

[Manuel Jesús Recena Soto]

Hello Kohsuke,

After knowing that the widespread idea is to use `github-plugin` so
that GitHub configuration is managed by this plugin, I think that my
last PR to `github-branch-source` does not make sense.

When I pushed this PR my goal was to improve (or try to do it) the
current form validation when the use sets a GitHub Enterpise server.
Only that.

Do you (KK, Jesse, Christopher, others...) agree if I close this PR?

Regards,

> --
> 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/CAN4CQ4z4dmuE53Of2b2wzTFEfjVZL2fehBaJ%3DZfyZyeVX86ktw%40mail.gmail.com.

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



--

[Manuel Jesús Recena Soto]

By the way Kohsuke, when you have a chance, create the Jira component
for this plugin. I have to move there these issues:

https://issues.jenkins-ci.org/browse/JENKINS-33242
https://issues.jenkins-ci.org/browse/JENKINS-32155
https://issues.jenkins-ci.org/browse/JENKINS-33243
etc...

Regards,

[Kohsuke Kawaguchi]

Done

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CABa-UofDBLoLqOgKgJRJVxDhZRQqXRErTdpHT6LqQc3nDP5oWw%40mail.gmail.com.

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

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

Which one? #30?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CABa-Uoc7%2BeZ2%3DmErX1X_cP-gGAzv6Zp2%2BgEY9s-YyJjfbM49OQ%40mail.gmail.com.

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

--

Kohsuke Kawaguchi

[Manuel Jesús Recena Soto]

Hello KK,

No, this one https://github.com/jenkinsci/github-branch-source-plugin/pull/27
(downstream of https://github.com/kohsuke/github-api/pull/251).

Regards,

> https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xkjoSoj8zqL_zWYVYWx_p584TpWN_5FYQcPmdeh8MFyw%40mail.gmail.com.