QUESTION: ssh-agent dependencies

[Victor Martinez]

Hi there,

 I'd like to know whether the ssh-agent plugin dependencies are wrong or not

Latest Release Latest Release Date Required Core Dependencies	1.8 (archives) Aug 07, 2015 1.609.1 ssh-credentials (version:1.11) credentials (version:1.22) workflow-step-api (version:1.9)

I wonder why those workflow-step-api plugin dependencies are there, I've found the below Jira: https://issues.jenkins-ci.org/browse/JENKINS-28689  But still I don't understand why those workflow steps plugin might be part of the ssh-agent. Basically I use puppet to configure Jenkins and its dependencies and now I'm forced somehow to install that new version and also its dependencies, and I don't like the way of having a bunch of new plugin dependencies

Just wondering if that's the expected behaviour or so

Thanks so much 

[Victor Martinez]

Hi again,

 In order to support the workflow plugin those dependent modules should be part of every plugin? If that's the case, is there any planning to add those features as part of the jenkins core? I like the idea of reducing the dependencies between plugins in order to use the Configuration as Code paradigm without worrying about those dependent plugins

Thanks again

[Baptiste Mathus]

Hi,

This dates from this commit back from 2015-08-24 by Manuel Recena: https://github.com/jenkinsci/ssh-agent-plugin/commit/010e968ab2ff8efa23a51d56d9046329140c96b5

from this PR https://github.com/jenkinsci/ssh-agent-plugin/pull/4

IIUC, this PR was supposed to add ssh-agent steps to DSL. Hence, IMO this is an example where the dependency from ssh-agent to workflow should have been added with <optional>true</optional> [1].

Manuel, did you make dependency required on purpose?

Cheers

--
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/2546f42f-2e1f-4aac-975a-f3dfd5e8eda1%40googlegroups.com.

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

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Kanstantsin Shautsou]

The same https://github.com/jenkinsci/credentials-binding-plugin/blob/master/pom.xml#L61-L65

[Manuel Jesús Recena Soto]

Hello,

As I said here [1], I'll review this dependency. But IIRC, It is necessary and is well configured.

Regards,

[1] https://github.com/jenkinsci/ssh-agent-plugin/pull/4#discussion_r41622070

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

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

--

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

[Kanstantsin Shautsou]

СС jglick

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/K7pf_W8NgqA/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/CABa-UodU016ayyyku8eN%3DZ6jYwvmV5TMXU%3Dd9OPQxqbZPZGpZg%40mail.gmail.com.

[Baptiste Mathus]

Maybe the rationale is that this dependency is not seen as a big problem since workflow-plugin is actually composed of many different plugins, and that that one is more a library plugin. 

Hence that's not gonna install the workflowJob type in a unintentional manner?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4B880F5C-D771-4D91-8CFC-2CFE715DF869%40gmail.com.

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

[Jesse Glick]

On Fri, Oct 9, 2015 at 4:19 AM, Victor Martinez
<victormar...@gmail.com> wrote:
> In order to support the workflow plugin those dependent modules should be part of every plugin?

Yes. The `workflow-step-api` plugin was expressly designed to be small
and devoid of UI so that it would be an unobjectionable dependency.
Optional dependencies cause lots of problems and should be avoided.

> I like the idea of reducing the dependencies between plugins in order to use the Configuration as Code paradigm without worrying about those dependent plugins

Why are you worrying about dependent plugins? When you include a
plugin in your set, include its transitive dependency graph (as the
Plugin Manager UI would). If the system you are using for enumerating
plugins does not provide a trivial way to flag & correct missing
transitive dependencies, fix that system.

[Daniel Beck]

On 09.10.2015, at 10:19, Victor Martinez <victormar...@gmail.com> wrote:

> In order to support the workflow plugin those dependent modules should be part of every plugin? If that's the case, is there any planning to add those features as part of the jenkins core? I like the idea of reducing the dependencies between plugins in order to use the Configuration as Code paradigm without worrying about those dependent plugins

Adding to what Jesse wrote: It should be fairly trivial to read the plugin dependencies from the HPI files and recursively (transitive dependencies) add them to your installation. I think I even did that as a bash script once.

[Jesse Glick]

On Fri, Oct 9, 2015 at 9:54 AM, Daniel Beck <m...@beckweb.net> wrote:
> read the plugin dependencies from the HPI files and recursively (transitive dependencies) add them to your installation

Yes, you can do that. I tend to recommend instead that the tool
building the image flag these as errors, and suggest additions to the
plugin list (ideally also showing the newest version available from
the update center, like `mvn dependency:show-dependency-updates` would
do). That way your image is always built deterministically and
explicitly from sources. If you ignore the update center and just add
the newest version transitively required, you also get determinism,
though it is then not obvious from looking at config sources what the
final plugin list will be, which can make debugging issues harder.

[Victor Martinez]

Thank for those answers and suggestions to solve those dependencies.

I can somehow wrap that functionality but as long as I use the puppet jenkins module I'm a bit exposed since it doesn't support those transitive dependencies (https://github.com/jenkinsci/puppet-jenkins/tree/master) at the moment.

I thought the ssh-agent plugin will be independent of those plugin dependencies since it was released more than 3 years ago and suddenly there was an unexpected new dependency with another plugin library. Maybe it was my bad since I didn't review those plugin dependencies but I wasn't expected it will a change.

On the other hand since the workflow plugin is an active plugin and being in development actively, I wonder whether that particular dependency won't affect it. 

Besides of that, what's the Jenkins strategy about the Workflow plugin? If it will be the standard process, shouldn't it be part of the core? IMO, it will help to avoid those new dependency transitive libraries.

Thanks again

[Jesse Glick]

On Fri, Oct 9, 2015 at 12:09 PM, Victor Martinez
<victormar...@gmail.com> wrote:
> since the workflow plugin is an active plugin and being in
> development actively, I wonder whether that particular dependency won't
> affect it.

How so? As of 1.0 there should be no incompatible API changes. (Even
if there were, it would only affect the Workflow step, which I presume
you are not using.)

> Besides of that, what's the Jenkins strategy about the Workflow plugin? If
> it will be the standard process, shouldn't it be part of the core?

Why? It does not need to be in core. If anything I would rather see
more things split out of the core into plugins. (There is a JIRA label
for this.)

[Victor Martinez]

I'll find out another way of adding transitive dependencies in a less insane way of reading the wiki and see those dependent plugins as you already suggested some good approaches. Even though I don't like the idea of forcing that dependent plugin, actually I like the way of JobDSL being less intrusive in order to support same plugins.

Thank you for your feedback

Cheers,

Víctor

[Arnaud Héritier]

Thus guys you are proposing to rewrite the dependencies resolution mechanism of maven and friends in bash ? Because I agree that for one dependency it works but in a real world when you have several dozen of plugins to deploy how many transitive dependencies will you have ? How will you resolve conflicts/constraints betweens dependencies ?

From my point of view we have nowadays no solution to propose such service if jenkins server isn’t started. The only solution is to start it and have it connected to internet and then to use jerkins-cli to correctly install the required plugins.

To come back the the workflow mandatory dependency to add in all compatible plugins I don’t really like it. It just smells bad. I understand that its not a core feature, it has a different lifecycle. This library will never be able to have a 2.0 version with backward incompatible changes without breaking several dozen or hundred of plugins (I cannot imagine you may non intentionnaly integrate such incompatible changes - clirr is your friend). I would have preferred (I think) a dedicated workflow library/plugin hosting all the integrations with all dependencies as optional.

Arnaud

[Jesse Glick]

On Fri, Oct 9, 2015 at 4:25 PM, Arnaud Héritier <aher...@gmail.com> wrote:
> you are proposing to rewrite the dependencies resolution mechanism of maven and friends in bash ?

Of course not! First of all I said nothing about Bash. Second, Jenkins
dependency semantics are pretty simple: plugins identified by a single
`shortName`, minimum versions using a fairly limited version parser,
optional flag. Nowhere near as complex as Maven dependencies.

> How will you resolve conflicts/constraints betweens dependencies ?

There are no conflicts or constraints. You pick the newest version
requested from any dependency, or even just pick the version offered
on the update center (ideally signaling an error if that is not new
enough for some dependency, which of course should not happen unless
someone else screwed up).

> we have nowadays no solution to propose such service if jenkins server isn’t started.

Why? Parsing out dependencies from plugin JAR manifests is a pretty
short Perl script or whatever. Or you could reuse Jenkins classes in
batch mode if you were writing the tool in Java;
`plugin-compat-tester` does that, for example.

> This library will never be able to have a 2.0 version with backward incompatible changes without breaking several dozen or hundred of plugins

Sure; that is true of any incompatible change in a widely used API,
which is why we strive hard to retain backward compatibility. What is
your point? Marking the dependency optional would make no difference.
Either you are using the WF step and you are affected, or you are not
using it and you are not affected.

> a dedicated workflow library/plugin hosting all the integrations

Unmaintainable and antimodular. We do not expect one plugin to host
all known `Builder` implementations so I do not see why `Step` should
be any different.