Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-29922

Promote delegates of metasteps to top-level functions, deprecate $class

      Currently you must write e.g.

      step([$class: 'JUnitResultArchiver', testResults: 'target/surefire-reports/*.xml'])
      

      which is awkward. Also in Snippet Generator you need to look under General Build Step for what to a user is logically a distinct step.

      Metasteps (step, wrap, checkout) should have an API by which they can declare that their delegate (scm in the last case) ought to be treated as a top-level step as far as DSL and Snippetizer are concerned, via some kind of syntactic sugar. In the absence of any Jenkins core API which would allow a Descriptor to specify a short name (yaml-project tries to define one of its own), this would have to be constructed somehow from the $class, perhaps simply:

      JUnitResultArchiver testResults: 'target/surefire-reports/*.xml'
      

      or with just one mandatory parameter even

      JUnitResultArchiver 'target/surefire-reports/*.xml'
      

      The follow-up question is what to do with nested Describable objects used in the configuration. So

      GitSCM ..., extensions: [[$class: 'PruneStaleBranch']]
      

      still looks unnatural. The Groovy builder idiom might suggest

      GitSCM ..., extensions: [PruneStaleBranch {}]
      

      though closure handling in JENKINS-26135 would need to be addressed first. Requires study to make a PoC.

          [JENKINS-29922] Promote delegates of metasteps to top-level functions, deprecate $class

          Jesse Glick added a comment -

          kohsuke proposes introducing a plugin (or other library?) with an annotation that could specify a script-friendly name (restricted to be a Java identifier, I suppose) for a Describable; the fallback value if not annotated could be the Class.simpleName. Using an annotation rather than a method on Descriptor ensures that mechanical indexers can run without executing code. Perhaps StepDescriptor.getFunctionName should also be deprecated in favor of the new annotation.

          Thus we could have something like

          junit testResults: '…'
          

          This could also be used in nested describables, using a builder pattern. Assuming annotations on GitSCM¹ & UserIdentity:

          gitSCM …, extensions: [identity {name = 'J. Q. Hacker', email = 'jqhacker@jenkins-ci.org'}]
          

          (JENKINS-30222 might need to be solved before adding support for nested describables, since we must ensure that these dynamically-generated functions are accessible not just in the sandbox but also in secondary CpsScript instances. Of course the existing technique in DSL may suffice without much work.)

          The builder pattern would allow us to replace $class on polymorphic (singleton or collection) properties. An open question is what, if anything, to do with monomorphic properties (usually collections). A quick recap:

          1. Prior to 1.0, all Describable values in properties needed to be instantiated directly as Java objects (constructor + setters). This is still allowed, but deprecated, since it forces you to import FQNs from plugins, and does not work in the sandbox.
          2. As of 1.0, a Describable should instead be specified as a Map<String,Object>, typically using the Groovy syntax for map literals.
            1. The implementation’s Class.name must in general be specified as a special key $class.
            2. $class may instead be a Class.simpleName when that is unambiguous.
            3. If a singleton property, or the element type of a collection-typed property, is monomorphic, $class may be omitted.
          3. The proposal here is to add a new and preferred option for specifying a nested Describable based on the builder pattern.

          So consider a monomorphic property such as GitSCM.userRemoteConfigs. We could either force it into the builder pattern as well:

          gitSCM userRemoteConfigs: [config {url = 'git@…', credentialsId = 'git-login'}, config {…}]
          

          or just leave it to use the map syntax as today (which we must continue to support for compatibility anyway):

          gitSCM userRemoteConfigs: [[url: 'git@…', credentialsId: 'git-login'}, […]]
          

          ¹Note that the identifier git is already taken by a custom step, so either we do not annotate GitSCM, or we use a different name, or the custom step wins and flows must use the Class.simpleName.

          ² Using the builder pattern also at top level, for steps, would be more consistent, but also more verbose, and perhaps incompatible:

          echo {message = 'hello world'}

          does not flow.

          Jesse Glick added a comment - kohsuke proposes introducing a plugin (or other library?) with an annotation that could specify a script-friendly name (restricted to be a Java identifier, I suppose) for a Describable ; the fallback value if not annotated could be the Class.simpleName . Using an annotation rather than a method on Descriptor ensures that mechanical indexers can run without executing code. Perhaps StepDescriptor.getFunctionName should also be deprecated in favor of the new annotation. Thus we could have something like junit testResults: '…' This could also be used in nested describables, using a builder pattern. Assuming annotations on GitSCM ¹ & UserIdentity : gitSCM …, extensions: [identity {name = 'J. Q. Hacker' , email = 'jqhacker@jenkins-ci.org' }] ( JENKINS-30222 might need to be solved before adding support for nested describables, since we must ensure that these dynamically-generated functions are accessible not just in the sandbox but also in secondary CpsScript instances. Of course the existing technique in DSL may suffice without much work.) The builder pattern would allow us to replace $class on polymorphic (singleton or collection) properties. An open question is what, if anything, to do with monomorphic properties (usually collections). A quick recap: Prior to 1.0, all Describable values in properties needed to be instantiated directly as Java objects (constructor + setters). This is still allowed, but deprecated, since it forces you to import FQNs from plugins, and does not work in the sandbox. As of 1.0, a Describable should instead be specified as a Map<String,Object> , typically using the Groovy syntax for map literals. The implementation’s Class.name must in general be specified as a special key $class . $class may instead be a Class.simpleName when that is unambiguous. If a singleton property, or the element type of a collection-typed property, is monomorphic, $class may be omitted. The proposal here is to add a new and preferred option for specifying a nested Describable based on the builder pattern. So consider a monomorphic property such as GitSCM.userRemoteConfigs . We could either force it into the builder pattern as well: gitSCM userRemoteConfigs: [config {url = 'git@…' , credentialsId = 'git-login' }, config {…}] or just leave it to use the map syntax as today (which we must continue to support for compatibility anyway): gitSCM userRemoteConfigs: [[url: 'git@…' , credentialsId: 'git-login' }, […]] ¹Note that the identifier git is already taken by a custom step, so either we do not annotate GitSCM , or we use a different name, or the custom step wins and flows must use the Class.simpleName . ² Using the builder pattern also at top level, for steps, would be more consistent, but also more verbose, and perhaps incompatible: echo {message = 'hello world' } does not flow.

          Jesse Glick added a comment -

          Hoping to solve JENKINS-30222 a different way.

          Jesse Glick added a comment - Hoping to solve JENKINS-30222 a different way.

          Andrew Bayer added a comment -

          I'd lean strongly towards the builder syntax, but I admit to personal preference there. Also worth mentioning though that the builder syntax will (I believe) require some changes in groovy-cps} (or at least {{workflow-cps) to not treat the nested closures as instances of CpsClosure, or we'll hit the always-fun over-eager returning of first completed nested closure issue.

          Andrew Bayer added a comment - I'd lean strongly towards the builder syntax, but I admit to personal preference there. Also worth mentioning though that the builder syntax will (I believe) require some changes in groovy-cps} (or at least {{workflow-cps ) to not treat the nested closures as instances of CpsClosure , or we'll hit the always-fun over-eager returning of first completed nested closure issue.

          I spent some time with jglick today to figure out the direction of this change.

          User Experience

          The proposed syntax for this, assuming @Symbol annotations on relevant classes, is as follows:

          // symbols on MercurialSCM, Kallithea
          // as for steps, if only mandatory params, can elide param name
          // @DataBoundConstructor public Kallithea(String url)
          hg source: 'https://whatever/',
            clean: true,
            browser: kallithea('https://whatever/')
          

          kallithea is implemented by DSL.invokeMethod and returns a map-like object that just captures the arguments. We are not going to actually instantiate KallitheaBrowser at this point since disambiguating the symbol might require a context.

          hg is similarly implemented by DSL.invokeMethod, but Jenkins knows that there's a meta step that can handle SCM, so in this case it instantiates the whole tree (including nested kallithea) into SCM instance and use the meta step to execute it.

          Design

          • Symbol plugin
            • A class that represents a nested describable object (which was formally a map), say, UninstantiatedDescribable
          • Workflow-Step-API
            • A new boolean method on StepDescriptor to recognize meta steps
          • Workflow-CPS-plugin
            • DSL.invokeMethod recognizes symbol and instantiate UninstantiatedDescribable
            • DSL.invokeMethod recognizes meta step and execute it on the spot
            • Snippetizer to recognize UninstantiatedDescribable during formatting

          Kohsuke Kawaguchi added a comment - I spent some time with jglick today to figure out the direction of this change. User Experience The proposed syntax for this, assuming @Symbol annotations on relevant classes, is as follows: // symbols on MercurialSCM, Kallithea // as for steps, if only mandatory params, can elide param name // @DataBoundConstructor public Kallithea( String url) hg source: 'https: //whatever/' , clean: true , browser: kallithea( 'https: //whatever/' ) kallithea is implemented by DSL.invokeMethod and returns a map-like object that just captures the arguments. We are not going to actually instantiate KallitheaBrowser at this point since disambiguating the symbol might require a context. hg is similarly implemented by DSL.invokeMethod , but Jenkins knows that there's a meta step that can handle SCM , so in this case it instantiates the whole tree (including nested kallithea) into SCM instance and use the meta step to execute it. Design Symbol plugin A class that represents a nested describable object (which was formally a map), say, UninstantiatedDescribable Workflow-Step-API A new boolean method on StepDescriptor to recognize meta steps Workflow-CPS-plugin DSL.invokeMethod recognizes symbol and instantiate UninstantiatedDescribable DSL.invokeMethod recognizes meta step and execute it on the spot Snippetizer to recognize UninstantiatedDescribable during formatting

          Change for the structs-plugin is ready

          Kohsuke Kawaguchi added a comment - Change for the structs-plugin is ready

          I need UninstantiatedDescribable to also support a single-object non-map parameter.

          Kohsuke Kawaguchi added a comment - I need UninstantiatedDescribable to also support a single-object non-map parameter.

          Change in pipeline CPS plugin is the umbrella PR.

          Kohsuke Kawaguchi added a comment - Change in pipeline CPS plugin is the umbrella PR.

          Please make one more reference implementation i.e. job-dsl.

          Kanstantsin Shautsou added a comment - Please make one more reference implementation i.e. job-dsl.

          Jesse Glick added a comment -

          integer if you mean a reference implementation of using @Symbol generally, that is already on daspilker’s radar I think. job-dsl has no reason to use the particular syntax proposed here; it is already using builder syntax with hand-coded symbols, so it would just be a matter of using the official annotation.

          Jesse Glick added a comment - integer if you mean a reference implementation of using @Symbol generally, that is already on daspilker ’s radar I think. job-dsl has no reason to use the particular syntax proposed here; it is already using builder syntax with hand-coded symbols, so it would just be a matter of using the official annotation.

          Yes, Job DSL already uses the Structs plugin for it's "Automatically Generated DSL" feature (couldn't find a better name...) , see https://github.com/jenkinsci/job-dsl-plugin/wiki/Automatically-Generated-DSL.

          Daniel Spilker added a comment - Yes, Job DSL already uses the Structs plugin for it's "Automatically Generated DSL" feature (couldn't find a better name...) , see https://github.com/jenkinsci/job-dsl-plugin/wiki/Automatically-Generated-DSL .

          Jesse Glick added a comment -

          Needs JENKINS-31582 in order to properly render metasteps.

          Jesse Glick added a comment - Needs JENKINS-31582 in order to properly render metasteps.

          Jesse Glick added a comment -

          Claimed complete. I promised to do a final code review.

          Jesse Glick added a comment - Claimed complete. I promised to do a final code review.

          Jesse Glick added a comment -

          I have added various changes.

          There is an important change which was forgotten here, which is to make the dropdown list in Snippet Generator inline metasteps. This could be done as a follow-up PR to workflow-cps I think.

          After release, follow-up PRs are also needed to pipeline-plugin/TUTORIAL.md, workflow-aggregator-plugin/demo/repo/Jenkinsfile (ought to finally use junit), and perhaps jenkins.io.

          Jesse Glick added a comment - I have added various changes. There is an important change which was forgotten here, which is to make the dropdown list in Snippet Generator inline metasteps. This could be done as a follow-up PR to workflow-cps I think. After release, follow-up PRs are also needed to pipeline-plugin/TUTORIAL.md , workflow-aggregator-plugin/demo/repo/Jenkinsfile (ought to finally use junit ), and perhaps jenkins.io .

          Jesse Glick added a comment -

          Realized that a metastep may not be inlined in the dropdown if it has any other parameters, as would be the case for checkout (which needs to be made a metastep too by the way; to start with, hg could be made a symbol): there would be no place to display the configuration controls for those other parameters. But step and wrap should qualify.

          Jesse Glick added a comment - Realized that a metastep may not be inlined in the dropdown if it has any other parameters, as would be the case for checkout (which needs to be made a metastep too by the way; to start with, hg could be made a symbol): there would be no place to display the configuration controls for those other parameters. But step and wrap should qualify.

          Jesse Glick added a comment - - edited

          Or checkout variants could be displayed inline, perhaps, if instance were set to a non-null meta-Step value, preconfigured with a delegate. There are two problems with that:

          • The dropdown to select a delegate would still be displayed, which would be confusing.
          • There is no API to create a default instance of the delegate. Normally a config view for the delegate would be displayed with a null instance, so default values in the form controls would be applied. But there is no way to simultaneously request that the delegate descriptor dropdown be preset to a given value, and avoid defining a specific instance of that descriptor.

          Possibly both issues could be addressed with an extra API honored by the views of the metastep. The second in isolation would be solved if attrs.default were defined here when used in inline mode. But to solve both would require the config view to switch modes when a delegateDescriptor were defined.

          Jesse Glick added a comment - - edited Or checkout variants could be displayed inline, perhaps, if instance were set to a non-null meta- Step value, preconfigured with a delegate. There are two problems with that: The dropdown to select a delegate would still be displayed, which would be confusing. There is no API to create a default instance of the delegate. Normally a config view for the delegate would be displayed with a null instance , so default values in the form controls would be applied. But there is no way to simultaneously request that the delegate descriptor dropdown be preset to a given value, and avoid defining a specific instance of that descriptor. Possibly both issues could be addressed with an extra API honored by the views of the metastep. The second in isolation would be solved if attrs.default were defined here when used in inline mode. But to solve both would require the config view to switch modes when a delegateDescriptor were defined.

          Jesse Glick added a comment -

          Also it looks like the DSLD/GDSL changes were not made yet.

          Jesse Glick added a comment - Also it looks like the DSLD/GDSL changes were not made yet.

          Jesse Glick added a comment -

          Nor has html.groovy, used for static documentation.

          Jesse Glick added a comment - Nor has html.groovy , used for static documentation.

          Jesse Glick added a comment -

          I also plan to deprecate the archive step when archiveArtifacts is available, though ArtifactArchiver needs a fix to default value handling.

          Jesse Glick added a comment - I also plan to deprecate the archive step when archiveArtifacts is available, though ArtifactArchiver needs a fix to default value handling.

          Jesse Glick added a comment -

          Parallel Test Executor demo updated on Docker Hub. PR filed for an update to the general CD demo.

          Jesse Glick added a comment - Parallel Test Executor demo updated on Docker Hub. PR filed for an update to the general CD demo.

          Jesse Glick added a comment -

          aheritier requests that documentation specify the earliest versions to support the simplified syntax.

          Jesse Glick added a comment - aheritier requests that documentation specify the earliest versions to support the simplified syntax.

          jglick yes at least a note somewhere explaining what in was and in which version the new syntax is available
          The old syntax is always supported or not ?

          Arnaud Héritier added a comment - jglick yes at least a note somewhere explaining what in was and in which version the new syntax is available The old syntax is always supported or not ?

          Jesse Glick added a comment -

          Yes the old system continues to be supported (in fact it is required in some cases). For that matter, the pre-1.0 syntax continues to be supported. The updated static reference page goes into detail.

          Jesse Glick added a comment - Yes the old system continues to be supported (in fact it is required in some cases). For that matter, the pre-1.0 syntax continues to be supported. The updated static reference page goes into detail.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          TUTORIAL.md
          http://jenkins-ci.org/commit/pipeline-plugin/d234db971a021ef58271f2e2724f1debd1d4f54f
          Log:
          JENKINS-29922 @aheritier requests some information about version availability.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: TUTORIAL.md http://jenkins-ci.org/commit/pipeline-plugin/d234db971a021ef58271f2e2724f1debd1d4f54f Log: JENKINS-29922 @aheritier requests some information about version availability.

          Jesse Glick added a comment -

          aheritier added a note here. It is tricky to specify up front what versions of everything you need to be running to get the new syntax, because there are a lot of updates working in combination. Snippet Generator offers the simplified syntax when it is available.

          Jesse Glick added a comment - aheritier added a note here . It is tricky to specify up front what versions of everything you need to be running to get the new syntax, because there are a lot of updates working in combination. Snippet Generator offers the simplified syntax when it is available.

          Jesse Glick added a comment -

          Filed JENKINS-37215 to track generated documentation updates.

          Jesse Glick added a comment - Filed JENKINS-37215 to track generated documentation updates.

          Jesse Glick added a comment -

          Just found that the @Symbol in the junit plugin does not work in Jenkins 1.x, I think because the plugin declares a dependency only on the annotation JAR, when really it needs a dependency on the structs plugin. In Jenkins 2.x, the inclusion of the annotation in core apparently lets it work.

          Jesse Glick added a comment - Just found that the @Symbol in the junit plugin does not work in Jenkins 1.x, I think because the plugin declares a dependency only on the annotation JAR, when really it needs a dependency on the structs plugin. In Jenkins 2.x, the inclusion of the annotation in core apparently lets it work.

          Jesse Glick added a comment -

          (Artificial class loading semantics in JenkinsRule probably hid this problem. Updating acceptance tests to prove that things work properly in a more realistic environment.)

          Jesse Glick added a comment - (Artificial class loading semantics in JenkinsRule probably hid this problem. Updating acceptance tests to prove that things work properly in a more realistic environment.)

          Jesse Glick added a comment -

          I filed JENKINS-37227 for the follow-up task of updating checkout.

          Jesse Glick added a comment - I filed JENKINS-37227 for the follow-up task of updating checkout .

          Jesse Glick added a comment -

          Everything now addressed other than the filed follow-up tasks.

          Jesse Glick added a comment - Everything now addressed other than the filed follow-up tasks.

          Code changed in jenkins
          User: Christian Pönisch
          Path:
          pom.xml
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/atx/ATXPublisher.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/generator/ReportGeneratorPublisher.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/junit/JUnitPublisher.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/log/ETLogPublisher.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/trf/TRFPublisher.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/test/TestFolderBuilder.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/test/TestPackageBuilder.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/test/TestProjectBuilder.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/tool/StartETBuilder.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/tool/StartTSBuilder.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/tool/StopETBuilder.java
          src/main/java/de/tracetronic/jenkins/plugins/ecutest/tool/StopTSBuilder.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/SystemTestBase.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/atx/ATXPublisherST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/generator/ReportGeneratorPublisherST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/junit/JUnitPublisherST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/log/ETLogPublisherST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/trf/TRFPublisherST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/test/TestFolderBuilderST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/test/TestPackageBuilderST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/test/TestProjectBuilderST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/tool/StartETBuilderST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/tool/StartTSBuilderST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/tool/StopETBuilderST.java
          src/test/java/de/tracetronic/jenkins/plugins/ecutest/tool/StopTSBuilderST.java
          http://jenkins-ci.org/commit/ecutest-plugin/a106a4bde217c6b907bfee4ba14c6569ebf333ae
          Log:
          added @Symbol annotation to simplify pipeline syntax

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christian Pönisch Path: pom.xml src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/atx/ATXPublisher.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/generator/ReportGeneratorPublisher.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/junit/JUnitPublisher.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/log/ETLogPublisher.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/report/trf/TRFPublisher.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/test/TestFolderBuilder.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/test/TestPackageBuilder.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/test/TestProjectBuilder.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/tool/StartETBuilder.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/tool/StartTSBuilder.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/tool/StopETBuilder.java src/main/java/de/tracetronic/jenkins/plugins/ecutest/tool/StopTSBuilder.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/SystemTestBase.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/atx/ATXPublisherST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/generator/ReportGeneratorPublisherST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/junit/JUnitPublisherST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/log/ETLogPublisherST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/report/trf/TRFPublisherST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/test/TestFolderBuilderST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/test/TestPackageBuilderST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/test/TestProjectBuilderST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/tool/StartETBuilderST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/tool/StartTSBuilderST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/tool/StopETBuilderST.java src/test/java/de/tracetronic/jenkins/plugins/ecutest/tool/StopTSBuilderST.java http://jenkins-ci.org/commit/ecutest-plugin/a106a4bde217c6b907bfee4ba14c6569ebf333ae Log: added @Symbol annotation to simplify pipeline syntax regarding to https://github.com/jenkinsci/pipeline-plugin/blob/master/DEVGUIDE.md#defining-symbols can be first used starting with workflow-cps 2.10 and structs 1.3 ( JENKINS-29922 ) identically named like the Job DSL extensions

          Code changed in jenkins
          User: Suresh Kumar P
          Path:
          pom.xml
          src/main/java/com/spcow/winrmclient/InvokeCommandWinRMOperation.java
          src/main/java/com/spcow/winrmclient/SendFileWinRMOperation.java
          src/main/java/com/spcow/winrmclient/WinRMClientBuilder.java
          http://jenkins-ci.org/commit/winrm-client-plugin/2b0caa5f52e3ed4f57b0a82c78507b15c4251867
          Log:
          Added Symbols for Jenkins Pipeline support

          JENKINS-29922 $class must die

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Suresh Kumar P Path: pom.xml src/main/java/com/spcow/winrmclient/InvokeCommandWinRMOperation.java src/main/java/com/spcow/winrmclient/SendFileWinRMOperation.java src/main/java/com/spcow/winrmclient/WinRMClientBuilder.java http://jenkins-ci.org/commit/winrm-client-plugin/2b0caa5f52e3ed4f57b0a82c78507b15c4251867 Log: Added Symbols for Jenkins Pipeline support JENKINS-29922 $class must die

          Code changed in jenkins
          User: Suresh Kumar P
          Path:
          pom.xml
          src/main/java/sp/sd/fileoperations/FileCopyOperation.java
          src/main/java/sp/sd/fileoperations/FileCreateOperation.java
          src/main/java/sp/sd/fileoperations/FileDeleteOperation.java
          src/main/java/sp/sd/fileoperations/FileDownloadOperation.java
          src/main/java/sp/sd/fileoperations/FileJoinOperation.java
          src/main/java/sp/sd/fileoperations/FileOperationsBuilder.java
          src/main/java/sp/sd/fileoperations/FilePropertiesToJsonOperation.java
          src/main/java/sp/sd/fileoperations/FileTransformOperation.java
          src/main/java/sp/sd/fileoperations/FileUnTarOperation.java
          src/main/java/sp/sd/fileoperations/FileUnZipOperation.java
          src/main/java/sp/sd/fileoperations/FolderCopyOperation.java
          src/main/java/sp/sd/fileoperations/FolderCreateOperation.java
          src/main/java/sp/sd/fileoperations/FolderDeleteOperation.java
          http://jenkins-ci.org/commit/file-operations-plugin/e0b44fcd8484372deef5a22e4daa048b4b5e8f46
          Log:
          Added Symbols for Jenkins Pipeline support

          JENKINS-29922 $class must die

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Suresh Kumar P Path: pom.xml src/main/java/sp/sd/fileoperations/FileCopyOperation.java src/main/java/sp/sd/fileoperations/FileCreateOperation.java src/main/java/sp/sd/fileoperations/FileDeleteOperation.java src/main/java/sp/sd/fileoperations/FileDownloadOperation.java src/main/java/sp/sd/fileoperations/FileJoinOperation.java src/main/java/sp/sd/fileoperations/FileOperationsBuilder.java src/main/java/sp/sd/fileoperations/FilePropertiesToJsonOperation.java src/main/java/sp/sd/fileoperations/FileTransformOperation.java src/main/java/sp/sd/fileoperations/FileUnTarOperation.java src/main/java/sp/sd/fileoperations/FileUnZipOperation.java src/main/java/sp/sd/fileoperations/FolderCopyOperation.java src/main/java/sp/sd/fileoperations/FolderCreateOperation.java src/main/java/sp/sd/fileoperations/FolderDeleteOperation.java http://jenkins-ci.org/commit/file-operations-plugin/e0b44fcd8484372deef5a22e4daa048b4b5e8f46 Log: Added Symbols for Jenkins Pipeline support JENKINS-29922 $class must die

            kohsuke Kohsuke Kawaguchi
            jglick Jesse Glick
            Votes:
            7 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: