Gave up Copyartifact2.0 / Request new maintainers to improve Copyartifact

[ikedam]

Hello all,
I'm Ikedam, a maintainer of Copyartifact plugin.

Two years ago, I planned and started to redesign Copyartifact (I called it Copyartifact 2.0) [1][2][3].

I decide to give it up as:

* I don't have enough time to continue that work
* Many planned features are already provided by run-selector plugin [4] and unarchive pipeline step [5]
    * Filter-based run selection
    * Supporting VirtualFile
* Redesigning costs too much, not for new features, but rather for preserving backward compatibilities.
    * Compatibilities for configurations (or features to migrate configurations)
    * Compatibilities for extensions by other plugins

I'm planning to resume maintaining Copyartifact based on the current design and implementations.
I believe it means Copyartifact would make no large improvements or introduce no new features,
and would become legacy and outdated in future.

There's a pull request to have Copyartifact support pipeline symbol expressions [6].
I believe it's reasonable to merge, but, on the other hand, I'm afraid it would result the compatibility issue more serious.

If someone want to maintain Copyartifact more active, that is,
supporting latest Jenkins features and introducing new features,
I want have him / her take over maintain Copyartifact.

Does someone want to do that?

Regards,
Ikedam

[1] https://groups.google.com/d/msg/jenkinsci-dev/LtuNuD2OkWY/rjdebD43DAAJ
[2] https://wiki.jenkins.io/display/JENKINS/Preview+for+Copy+Artifact+2.0
[3] https://issues.jenkins-ci.org/browse/JENKINS-24892
[4] https://wiki.jenkins.io/display/JENKINS/Run+Selector+Plugin
[5] https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-unarchive-code-copy-archived-artifacts-into-the-workspace
[6] https://github.com/jenkinsci/copyartifact-plugin/pull/88

[Jesse Glick]

On Sun, Sep 10, 2017 at 6:38 PM, ikedam <iked...@gmail.com> wrote:
> There's a pull request to have Copyartifact support pipeline symbol
> expressions [6].
> I believe it's reasonable to merge, but, on the other hand, I'm afraid it
> would result the compatibility issue more serious.

Perhaps it would be best to leave CopyArtifact as it is, useful for
freestyle projects, and introduce a separate much simpler plugin for
use from Pipeline…or even a single step for `workflow-basic-steps`.
Like `unarchive` (perhaps even an option to it), but accepting a job
name and build number as simple parameters. No need for “run
selectors” since a properly written job chain will have the upstream
pass the build number downstream as a parameter, though you could
accept a permalink like `lastStable` in lieu of a number. All of the
complexity around build selectors, filters, copy methods, etc. is
really not needed for Pipeline.

[R. Tyler Croy]

(replies inline)

On Mon, 11 Sep 2017, Jesse Glick wrote:

> On Sun, Sep 10, 2017 at 6:38 PM, ikedam <iked...@gmail.com> wrote:
> > There's a pull request to have Copyartifact support pipeline symbol
> > expressions [6].
> > I believe it's reasonable to merge, but, on the other hand, I'm afraid it
> > would result the compatibility issue more serious.
>
> Perhaps it would be best to leave CopyArtifact as it is, useful for
> freestyle projects, and introduce a separate much simpler plugin for

> use from Pipeline???or even a single step for `workflow-basic-steps`.

> Like `unarchive` (perhaps even an option to it), but accepting a job

> name and build number as simple parameters. No need for ???run
> selectors??? since a properly written job chain will have the upstream

> pass the build number downstream as a parameter, though you could
> accept a permalink like `lastStable` in lieu of a number. All of the
> complexity around build selectors, filters, copy methods, etc. is
> really not needed for Pipeline.

Your suggestion made me chuckle because I conned Kohsuke into adding Pipeline
support to Copy Artifact after breaking the news to him that 'unarchive'
doesn't do what he thought it did.



I would encourage adoption of the Copy Artifact plugin and incorporation of
Pipeline support into that rather than building another plugin. There are 34k
installs of the plugin which would potentially benefit from switching.


Cheers

- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

[Jesse Glick]

On Mon, Sep 11, 2017 at 11:44 AM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> I would encourage adoption of the Copy Artifact plugin and incorporation of
> Pipeline support into that

It already works from Pipeline—Tom Fennelly did that two and half
years ago. I am just pointing out that it is overkill.

[R. Tyler Croy]

(replies inline)

On Mon, 11 Sep 2017, Jesse Glick wrote:

> On Mon, Sep 11, 2017 at 11:44 AM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > I would encourage adoption of the Copy Artifact plugin and incorporation of
> > Pipeline support into that
>

> It already works from Pipeline???Tom Fennelly did that two and half

> years ago. I am just pointing out that it is overkill.

From my perspective, something available via step() might as well not exist as
far as most users are concerned. From my understanding Kohsuke's work was
primarily adding @Symbol annotations, which I don't understand how that could
possibly be overkill.


Anyways, I'll let you and Kohsuke discuss the future of this since you two feel
most passionately about it.

[Jesse Glick]

On Mon, Sep 11, 2017 at 12:32 PM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> Kohsuke's work was
> primarily adding @Symbol annotations, which I don't understand how that could
> possibly be overkill.

That *PR* is not overkill. It is a simple change which I would approve
as soon as there are tests.

I was saying use of the whole *plugin* from Pipeline is overkill. Most
of its code exists to work around the inflexibility of traditional job
types. All that is really needed is for

https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/33f80556adf735ef01f2d62def1dfa13d7a6bed6/src/main/java/org/jenkinsci/plugins/workflow/steps/ArtifactUnarchiverStepExecution.java#L36

to be supported by a `String jobName` + `String build` or something like that.

[Oleg Nenashev]

Hi,

If somebody is interested in taking ownership of this plugin, note that the Run Selector bits bits have been already refactored by Alex Somai during GSoC 2016. https://github.com/jenkinsci/run-selector-plugin . This plugin offers all selectors as pipeline-compatible implementations with Symbols (example, selectRun()).

Whomever takes ownership of the plugin, it may be useful to integrate Copy Artifacts plugin with a new implementation of Run selectors.

BR, Oleg

понедельник, 11 сентября 2017 г., 19:52:29 UTC+2 пользователь Jesse Glick написал:

[Jesse Glick]

On Fri, Sep 15, 2017 at 3:52 PM, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> Run Selector bits bits have been already refactored by Alex Somai during
> GSoC 2016. https://github.com/jenkinsci/run-selector-plugin . This plugin
> offers all selectors as pipeline-compatible implementations with Symbols

I would argue you should not use this facility. Normally you only need
a fixed number (passed in from somewhere); or a permalink if you are
on a scheduled trigger rather than strictly downstream. Filtering, if
actually required, would be more flexibly and transparently handled
using script logic (`RunWrapper`).