revisit ToolInstallation "(Default)"

[nicolas de loof]

Hi,

User experience when using ToolInstalation is odd.

Most (all but maven afaik) Tools do define a "(Default)" implicit ToolInstallation, which actually resolves to system PATH

When user wants to make his Jenkins setup predictable, he has to edit all jobs to ensure specific ToolInstallation is selected. There's no way to make one the "Default" for new jobs

JDK makes things even stranger as defining one (and only one) ToolInstallation do change the meaning for "(Default)" to "the sole one configured"

I'd like to establish guideline for ToolInstallation and a better UX

• When installed/upgraded, ToolInstallation define some explicit "System" ToolInstallation to resolve as PATH. Administrator can just delete it if this makes sense for his setup. 
  
• ToolInstallation Descriptor define a default installation the admin can select from system config UI. This one always get resolve by empty ID (i.e. "(Default)"). During install/initial upgrade to a version with revisited ToolInstallation behavior, "System" is selected
• ToolInstallation selector only get displayed on UI when there's more than just on installation

I plan to experiment with this approach on some early development plugin before I try to apply to existing ones then JDK in jenkins-core

any thought ?

[Surya Gaddipati]

Hi Nicolas, 

I am a little confused as to what 'ToolInstalation' means. 

This might obviously my personal opinion. But  Jenkins feels like its too tied to the java world . JDK/Maven versions ect should *not* be part jenkins core. 

Lots of companies have/are moving from monolithic java/ruby apps to *microservices*  and typically use a wide range of technologies and language versions. 

Surya

[Mark Waite]

I believe the "ToolInstallation" to which he refers is a general purpose concept that is used in many plugins.  The git plugin (for example) allows the user to define the location of the git program at the system level, and per slave.  That allows me to adapt the Jenkins slave for the git that is installed on the "D:" drive of one Windows machine, the "C:" drive of another Windows machine, and in a completely non-standard location on a more exotic machine.

The concept of "ToolInstallation" is likely also applied to the mercurial executable, the perforce "p4" executable, and several other external tools.  As far as I know, it is not Java specific.

I don't have an opinion on Nicolas' proposal...

Mark Waite

--
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/d28a21db-1fd7-4bc1-a5d6-942fefcf86d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vincent Latombe]

+1 on Nicolas's proposal, I got hit several times by incorrect slaves configuration picking up a Maven installation in PATH instead of using one of the Jenkins-defined installations.

Vincent

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtG%3DYvx9jJ7-V%3D6dGnbh%2BmC0DiaQ%2BNRZpb9StzRmmgLD1g%40mail.gmail.com.

[Martin Weber]

Am Mittwoch, 1. Juli 2015, 22:41:55 schrieb nicolas de loof:
> Hi,
>
> User experience when using ToolInstalation is odd.

[...]
> - When installed/upgraded, ToolInstallation define some explicit

> "System" ToolInstallation to resolve as PATH. Administrator can just
> delete it if this makes sense for his setup.

+1
My plugin uses 'InSearchPath' as the name.

> - ToolInstallation Descriptor define a default installation the admin

> can select from system config UI. This one always get resolve by empty ID
> (i.e. "(Default)"). During install/initial upgrade to a version with
> revisited ToolInstallation behavior, "System" is selected

Maybe I misunderstand this, I prefer to have the build fail if the job's tool
cannot be detected rather than let Jenkins chose one on its own.

> - ToolInstallation selector only get displayed on UI when there's more
> than just on installation

- ToolInstallation should have stable references to/from job tool selection.
Currently, if you change the name of a tool on the system config page, each
job that uses that tool, forgets which one is selected.

Martin

--
Cd wrttn wtht vwls s mch trsr.

[nicolas de loof]

Yes, that's another point I'd like to address: assign a unique ID to tool installations and/or offer a new listener API so job can be reconfigured on change. But this is a distinct issue I plan to investigate later. I guess fixing this crazy "(Default)" behaviour would help me to have a better understanding of possible impacts.

--
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/1679998.BB3CbPbEGy%40linux.

[Martin Weber]

Am Donnerstag, 2. Juli 2015, 18:23:08 schrieb nicolas de loof:
> Yes, that's another point I'd like to address: assign a unique ID to tool
> installations and/or offer a new listener API so job can be reconfigured on

I already did some experiments on that, but I used an artificial surrogate PID
(persistence ID, an integer), unique to the type of my tool which is passed
to/from the global config page as a hidden form-field.
Any PID is considered to be unchanged as long as the ToolInstallation object
is present in global config.

BuildSteps inside jobs in turn just reference the selected tool installation
by its never changing PID (instead of its name as currently, which causes the
annoying behavior).
That way, build steps do not have to implement to implement a listener API.

A special value of (zero, NULL or -1) indicates a ToolInstallation that is new
in terms of global configuration (has never been saved). If global config page
is saved, a unique PID must be computed, assigned and persisted in XML.

In my experiment, when the global config page is saved or applied, I iterate
over all incoming ToolInstallation objects and determine if one has the 'never
saved' special PID. If so, a new unique PID gets then computed as 'highest
known PID' + 1 and gets assigned before saving. (I also implemented an
algorithm to make PID values small in terms of bytes to transfer in a form-
round-trip.)
Unfortunately, this PID computation will produce duplicated PIDs, if more than
one admin added a new ToolInstalllation and submits the global config form at
the same time.

IMHO, PIDs are the way to approach the problem, not listeners.

[nicolas de loof]

Right, I'll keep this in mind, and such a solution does not forbid to offer listeners as well

Anyway this is another (major) topic to be addressed later.

--
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/10262750.VWKpoA5dKT%40linux.

[Jesse Glick]

On Thu, Jul 2, 2015 at 6:09 PM, Martin Weber <fifteen...@gmail.com> wrote:
> BuildSteps inside jobs in turn just reference the selected tool installation
> by its never changing PID (instead of its name as currently, which causes the
> annoying behavior).

I think I would be -1 on this. Like `Item`s, `ToolInstallation`s are
intentionally referred to by `name`. Thus there is no magical state,
and scripted builds (Workflow, YAML Project, Job DSL, …) can refer to
the same ID the UI uses.

[Jesse Glick]

+1 on your proposal except

On Wed, Jul 1, 2015 at 4:41 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> ToolInstallation selector only get displayed on UI when there's more than just on[e] installation

I would recommend the selector be displayed unconditionally. Principle
of least surprise. Even if you do currently only have one
installation, it is nice to be able to discover from a job
configuration screen that you *could* pick a different one.