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

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

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Kohsuke Kawaguchi 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.

            Show
            jglick Jesse Glick added a comment - Kohsuke Kawaguchi 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.
            Hide
            jglick Jesse Glick added a comment -

            Hoping to solve JENKINS-30222 a different way.

            Show
            jglick Jesse Glick added a comment - Hoping to solve JENKINS-30222 a different way.
            Hide
            abayer 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.

            Show
            abayer 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.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            I spent some time with Jesse Glick 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
            Show
            kohsuke Kohsuke Kawaguchi added a comment - I spent some time with Jesse Glick 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
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Change for the structs-plugin is ready

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

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

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

            Change in pipeline CPS plugin is the umbrella PR.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Change in pipeline CPS plugin is the umbrella PR.
            Hide
            integer Kanstantsin Shautsou added a comment -

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

            Show
            integer Kanstantsin Shautsou added a comment - Please make one more reference implementation i.e. job-dsl.
            Hide
            jglick Jesse Glick added a comment -

            Kanstantsin Shautsou if you mean a reference implementation of using @Symbol generally, that is already on Daniel Spilker’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.

            Show
            jglick Jesse Glick added a comment - Kanstantsin Shautsou if you mean a reference implementation of using @Symbol generally, that is already on Daniel Spilker ’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.
            Hide
            daspilker 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.

            Show
            daspilker 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 .
            Hide
            jglick Jesse Glick added a comment -

            Needs JENKINS-31582 in order to properly render metasteps.

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

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

            Show
            jglick Jesse Glick added a comment - Claimed complete. I promised to do a final code review.
            Hide
            jglick 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.

            Show
            jglick 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 .
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jglick Jesse Glick added a comment -

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

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

            Nor has html.groovy, used for static documentation.

            Show
            jglick Jesse Glick added a comment - Nor has html.groovy , used for static documentation.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jglick Jesse Glick added a comment -

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

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

            Arnaud Héritier requests that documentation specify the earliest versions to support the simplified syntax.

            Show
            jglick Jesse Glick added a comment - Arnaud Héritier requests that documentation specify the earliest versions to support the simplified syntax.
            Hide
            aheritier Arnaud Héritier added a comment -

            Jesse Glick 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 ?

            Show
            aheritier Arnaud Héritier added a comment - Jesse Glick 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 ?
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            jglick Jesse Glick added a comment -

            Arnaud Héritier 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.

            Show
            jglick Jesse Glick added a comment - Arnaud Héritier 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.
            Hide
            jglick Jesse Glick added a comment -

            Filed JENKINS-37215 to track generated documentation updates.

            Show
            jglick Jesse Glick added a comment - Filed JENKINS-37215 to track generated documentation updates.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jglick 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.)

            Show
            jglick 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.)
            Hide
            jglick Jesse Glick added a comment -

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

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

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

            Show
            jglick Jesse Glick added a comment - Everything now addressed other than the filed follow-up tasks.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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

              People

              • Assignee:
                kohsuke Kohsuke Kawaguchi
                Reporter:
                jglick Jesse Glick
              • Votes:
                7 Vote for this issue
                Watchers:
                20 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: