Announcing copyartifact-git-plugin

[Patrick Higgins]

I just created https://github.com/patrick-higgins/copyartifact-git-plugin.

This plugin extends the Copy Artifact plugin by adding a build selector for the latest build from a named git branch.

I would like to host this plugin at github.com/jenkinsci. I believe I already have commit privilege but don't seem to be able to create new repos. Can someone fork my existing project into the jenkinsci organization?

Regards,

Patrick

[Richard Bywater]

Sounds interesting - I'd question whether it would be better to update the existing "copy artifact" plugin with your new functionality rather than create a separate one though?

Richard.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Jesse Glick]

On Wed, Feb 19, 2014 at 7:11 PM, Richard Bywater <ric...@byh2o.com> wrote:
> better to update the existing "copy artifact" plugin with your new functionality

No, adding a Git dependency to this generic plugin would not be a good idea.

[Richard Bywater]

Woops my bad - the way I read the description was that the plugin was a "clone" of the copy artifact plugin rather than just an additional selector for the copy artifact plugin.

Apologies for the noise :)

Richard.

[Patrick Higgins]

I didn't see a great way to implement what I want, so this is the simplest stopgap to fill my need.

It is a separate plugin for the reason Jesse mentioned--to not add a git dependency to a generic plugin.

Long-term, it seems like it would be nice if builds had a method to return the branch(es) associated with a build without needing any SCM dependencies. I'm not sure that a generic interface is possible across all SCM systems, though.

In lieu of that, I think it would be helpful to write a plugin that has optional dependencies on several SCM plugins and provides the branch information for a build based on the SCM plugins it finds at runtime. Would such a plugin be possible? If so, then copyartifact could come to depend on it, or another plugin similar to copyartifact-git could expose a selector based on it.

--
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/lHF6peILIFA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

[Daniel Beck]

On 20.02.2014, at 01:18, Jesse Glick <jgl...@cloudbees.com> wrote:

> No, adding a Git dependency to this generic plugin would not be a good idea.

Couldn't this trivially be implemented as an optional dependency? Or do you also consider those to be a problem?

[Jesse Glick]

On Wed, Feb 19, 2014 at 8:07 PM, Patrick Higgins
<patrick.al...@gmail.com> wrote:
> write a plugin that has
> optional dependencies on several SCM plugins and provides the branch
> information for a build based on the SCM plugins it finds at runtime.

Rather write a plugin with no dependencies which defines this API and
nothing more, and have various SCM plugins depend on it.

(And @Daniel yes I consider optional dependencies to be problems.)

[Stephen Connolly]

They are certainly an issue when it comes to plugin upgrades and compat testing

[Stephen Connolly]

What is needed is a way for plugins to identify that they are extensions for a specific plugin (as differentiated from direct depending on)

That way when you select the scm-api plugin you would also have a visual indicator that the git, subversion and mercurial plugins are designed to work with this API...

Better yet is when you have plugin A and plugin B installed that it tells you that plugin C is designed to be a functionality connector between A & B...

The issue is one of discovery. People use optional dependencies to put the connector stuff in say plugin B, so when you have A & B installed the connector functionality works. But better is to keep A & B with no knowledge of each other and then have C (with a hard dependency on both) provide the interconnect functionality... of course how do you know to install C in the first place?