(current feature)
      Copyartifact 1.34 introduced integration with workflow plugin.
      You can use copyartifact in workflow jobs like this:

      step([
        $class: 'CopyArtifact', projectName: 'test', filter: '**/*',
        selector: [$class: 'StatusBuildSelector', stable: false]
      ])
      

      (expected improvement)
      Workflow plugin provides plugins a way to define its own step functions like this:

      copyartifact projectName: 'test', filter: '**/*', selector: [$class: 'StatusBuildSelector', stable: false]
      

          [JENKINS-31247] Copyartifact: more integration with workflow

          ikedam added a comment -

          Workflow integration for htmlpublisher plugin looks good example for this extension.
          https://github.com/jenkinsci/htmlpublisher-plugin/pull/15

          ikedam added a comment - Workflow integration for htmlpublisher plugin looks good example for this extension. https://github.com/jenkinsci/htmlpublisher-plugin/pull/15

          ikedam added a comment -

          Is it possible to simplify also selector like this ?

          copyartifact projectName: 'test', filter: '**/*', selector: StatusBuildSelector(false)
          

          ikedam added a comment - Is it possible to simplify also selector like this ? copyartifact projectName: 'test' , filter: '**/*' , selector: StatusBuildSelector( false )

          Jesse Glick added a comment -

          An implementation of JENKINS-29922 would simplify the syntax without any action on your part.

          You would benefit from a custom step only if the semantics were indeed simpler or different for Workflow. For example, some of the more exotic logic elements proposed for Copy Artifact 2.0 (and even some of the logic in 1.x) could be written directly in the user’s Groovy code, using if-statements and loops and so on.

          Yes the result would be somewhat more verbose, but on the other hand it is clear without reading any external documentation what the script is really doing, and you can make minor customizations (“pick the last stable build, or an unstable build if there has been no stable build in the past week”) without having to wait for your weird use case to be supported in the Jenkins plugin code. Common use cases can be packaged as script libraries or just written up as examples in plugin documentation.

          Enabling this kind of usage means providing lower-level steps and/or Groovy objects that can offer safe (@Whitelisted) access to critical information about Jenkins builds. There is already a RunWrapper in Workflow, though currently available only as currentBuild or the return value of the build step; could be expanded to let you get, say, the lastBuild of a job which you have Item.READ access to.

          Jesse Glick added a comment - An implementation of JENKINS-29922 would simplify the syntax without any action on your part. You would benefit from a custom step only if the semantics were indeed simpler or different for Workflow. For example, some of the more exotic logic elements proposed for Copy Artifact 2.0 (and even some of the logic in 1.x) could be written directly in the user’s Groovy code, using if -statements and loops and so on. Yes the result would be somewhat more verbose, but on the other hand it is clear without reading any external documentation what the script is really doing, and you can make minor customizations (“pick the last stable build, or an unstable build if there has been no stable build in the past week”) without having to wait for your weird use case to be supported in the Jenkins plugin code. Common use cases can be packaged as script libraries or just written up as examples in plugin documentation. Enabling this kind of usage means providing lower-level steps and/or Groovy objects that can offer safe ( @Whitelisted ) access to critical information about Jenkins builds. There is already a RunWrapper in Workflow, though currently available only as currentBuild or the return value of the build step; could be expanded to let you get, say, the lastBuild of a job which you have Item.READ access to.

          ikedam added a comment -

          Thanks.
          It sounds better to wait JENKINS-29922.

          Are there already steps called with code blocks? (like if-statements)
          I plan to introduce a build filter that users can declare with groovy scripts (integrating with script-security) in a future release, and want to see if I can make it easier to use that in workflow jobs.

          ikedam added a comment - Thanks. It sounds better to wait JENKINS-29922 . Are there already steps called with code blocks? (like if-statements) I plan to introduce a build filter that users can declare with groovy scripts (integrating with script-security) in a future release, and want to see if I can make it easier to use that in workflow jobs.

          Jesse Glick added a comment -

          Are there already steps called with code blocks?

          Yes, a step may declare that it takes a closure, which it can run zero or more times at its discretion (for example according to return value or thrown exception).

          Jesse Glick added a comment - Are there already steps called with code blocks? Yes, a step may declare that it takes a closure, which it can run zero or more times at its discretion (for example according to return value or thrown exception).

          ikedam added a comment -

          Thanks. I found out documents and examples for passing code blocks.

          It may be written like this:

          copyartifact projectName: 'upstream' {
              return run.resuli.isBetterOrEquals(Result.SECCESS);
          }
          

          ikedam added a comment - Thanks. I found out documents and examples for passing code blocks. Creating a block-scoped step TimeoutStep.java TimeoutStepExecution.java TimeoutStepTest.java It may be written like this: copyartifact projectName: 'upstream' { return run.resuli.isBetterOrEquals(Result.SECCESS); }

          Jesse Glick added a comment -

          Could, but seems a bit unnatural since the block is not the main point of the step, it is just a simple function. For these kinds of cases see my comment of a couple of days ago about lower-level steps and Groovy value objects.

          Jesse Glick added a comment - Could, but seems a bit unnatural since the block is not the main point of the step, it is just a simple function. For these kinds of cases see my comment of a couple of days ago about lower-level steps and Groovy value objects.

          Ken Rachynski added a comment -

          I was just looking for this functionality in 1.38.1 and see that this request has been idle for just over a year.

          Ken Rachynski added a comment - I was just looking for this functionality in 1.38.1 and see that this request has been idle for just over a year.

          Is this ticket OBE with 1.39?

          Aaron D. Marasco added a comment - Is this ticket OBE with 1.39?

          ikedam added a comment -

          Pipeline expressions are now supported in copyartifact-1.39, JENKINS-46700 .

          ikedam added a comment - Pipeline expressions are now supported in copyartifact-1.39, JENKINS-46700 .

          ikedam added a comment -

          Out-of-Body Experience?

          ikedam added a comment - Out-of-Body Experience?

          ikedam Overcome By Events, sorry.

          Aaron D. Marasco added a comment - ikedam Overcome By Events, sorry.

          ikedam added a comment -

          aarondmarasco_vsi Oh, I got. Thanks!

          ikedam added a comment - aarondmarasco_vsi Oh, I got. Thanks!

            Unassigned Unassigned
            ikedam ikedam
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: