• Custom Tools Compatibility

      Add support for workflow

      Acceptance criteria from the plugin maintainer (oleg_nenashev

      • UsedCustomToolsAction RunAction2, which tracks the list of required tools
      • "Install custom tool" simple build step, which adds the tool to the scope of the task (AbstractProject or Pipeline's node() scope). Stores data in UsedCustomToolsAction. Pipeline alias - e.g. customTool()
      • Ability to contribute environment variables for launched scripts, likely with a new LauncherDecorator method (decorate(Launcher launcher, Job job, Node node) or so) - depends on JENKINS-TODO, can be done in a compatible way
      • Update the DecoratedLauncher implementation and to move it outside the BuildWrapper to the new LauncherDecorator
      • New DecoratedLauncher implementation pulls information about tools from UsedCustomToolsAction and then initializes it, similarly to what it does now with pulling from the Build Wrapper
      • Automatic test(s) for the common use-cases in Pipeline (see the requirements below)
      • Documentation, can be written in a new page within the GitHub repository (Wiki must die soon). This documentation should describe the logic and provide examples.

      Extra requirements:

      • The version engine is supported including the Tool Version parameter. Should be no problems with that, but needs testing
      • The resolution of variables in the step takes other Node and Job environment variables into account

      Nice2have, optional:

      • Some UI, which improves tracking of tool usage in UsedCustomToolsAction - really important for multi-log Pipeline
      • Support definition of tools on the global level (for all node() calls)
      • CustomToolsBuildWrapper is reworked to the SimpleBuildWrapper
        • oleg_nenashev: Not really required if there is a buildStep described above
      • Common tool() step is able to invoke the customTool() logic somehow.

       

          [JENKINS-30680] Make Custom Tools compatible with Pipeline

          Code changed in jenkins
          User: Nigel Harniman
          Path:
          COMPATIBILITY.md
          TUTORIAL.md
          http://jenkins-ci.org/commit/workflow-plugin/78a20d902c6ac5c069cfc4f38bdade36e109cc4c
          Log:
          Noting JENKINS-30680

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nigel Harniman Path: COMPATIBILITY.md TUTORIAL.md http://jenkins-ci.org/commit/workflow-plugin/78a20d902c6ac5c069cfc4f38bdade36e109cc4c Log: Noting JENKINS-30680

          Code changed in jenkins
          User: Nigel Harniman
          Path:
          COMPATIBILITY.md
          http://jenkins-ci.org/commit/workflow-plugin/5ebcdcb06c61faf2e0c4e8dc0c2fbdf7ede70267
          Log:
          Noting JENKINS-30680

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nigel Harniman Path: COMPATIBILITY.md http://jenkins-ci.org/commit/workflow-plugin/5ebcdcb06c61faf2e0c4e8dc0c2fbdf7ede70267 Log: Noting JENKINS-30680

          Code changed in jenkins
          User: Jesse Glick
          Path:
          COMPATIBILITY.md
          http://jenkins-ci.org/commit/workflow-plugin/9d94b720d9f225d4f0f82d61e8f7599dbdabaa1f
          Log:
          Merge pull request #214 from harniman/master

          Noting JENKINS-30680

          Compare: https://github.com/jenkinsci/workflow-plugin/compare/47f0fb752d20...9d94b720d9f2

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: COMPATIBILITY.md http://jenkins-ci.org/commit/workflow-plugin/9d94b720d9f225d4f0f82d61e8f7599dbdabaa1f Log: Merge pull request #214 from harniman/master Noting JENKINS-30680 Compare: https://github.com/jenkinsci/workflow-plugin/compare/47f0fb752d20...9d94b720d9f2

          Oleg Nenashev added a comment -

          Converting it to EPIC

          Oleg Nenashev added a comment - Converting it to EPIC

          Alex Johnson added a comment -

          Sub-child story but we can't link a epic to an epic because JIRA

          Alex Johnson added a comment - Sub-child story but we can't link a epic to an epic because JIRA

          Alex Johnson added a comment -

          Proposed syntax. Requires separate CustomToolStep class. The only required parameter would be the tool name, but would take all the same parameters as the CustomToolInstallWrapper. I think in Pipeline it makes the most sense (assuming they can be installed with one "wrapper") to write multiple tools like the following:

           

          customTool(name: 'nodejs', version: '4.8.3')
          customTool('gulp')
          customTool(name: 'webpack', version: '1.12')

           

          Without separate CustomToolStep class and using symbol annotations and SimpleBuildWrapper something close to the following can be achieved.

           

          customTool([tool(name: 'nodejs'), tool(name: 'webpack', version: '1.12')])
          

           

           

          Alex Johnson added a comment - Proposed syntax. Requires separate CustomToolStep class. The only required parameter would be the tool name, but would take all the same parameters as the CustomToolInstallWrapper. I think in Pipeline it makes the most sense (assuming they can be installed with one "wrapper") to write multiple tools like the following:   customTool(name: 'nodejs' , version: '4.8.3' ) customTool( 'gulp' ) customTool(name: 'webpack' , version: '1.12' )   Without separate CustomToolStep class and using symbol annotations and SimpleBuildWrapper something close to the following can be achieved.   customTool([tool(name: 'nodejs' ), tool(name: 'webpack' , version: '1.12' )])    

          alexbrjo what would be the syntax in a declarative pipeline?

          Dominik Bartholdi added a comment - alexbrjo what would be the syntax in a declarative pipeline?

          Oleg Nenashev added a comment -

          Just to set expectation, I do not have time to work on it anytime soon due to the lack of time. Some bits have been delivered for JCasC support though. I will likely have to mark the plugin for adoption.  

          If somebody is interested to take over the plugin, please let me know. There is also an option to add the Plugin revamp as a Google Summer of Code project idea. I will be happy to do it if somebody wants to be a co-mentor

          Oleg Nenashev added a comment - Just to set expectation, I do not have time to work on it anytime soon due to the lack of time. Some bits have been delivered for JCasC support though. I will likely have to mark the plugin for adoption.   If somebody is interested to take over the plugin, please let me know. There is also an option to add the Plugin revamp as a Google Summer of Code project idea. I will be happy to do it if somebody wants to be a co-mentor

          out of curiosity, what is wrong with just using it via current "tool" step support? Why do we need a custom step for this?

          Michael Lasevich added a comment - out of curiosity, what is wrong with just using it via current "tool" step support? Why do we need a custom step for this?

          out of curiosity, what is wrong with just using it via current "tool" step support? Why do we need a custom step for this?

          Using a Custom Tool from a Pipeline (with "tool") kind of works; the tool gets installed, and you get back the path to its homedir.  But:

          • if the tool declares extra PATH entries (for instance for a "bin" sub-folder), you must know it, and set the PATH+BLAH accordingly in your "withEnv" wrapper arguments
          • if the tool declares other extra environment variables, you must know it too, and explicitly define them in your Pipeline, again using "withEnv"

          So basically, you must be aware of some internal details of the Custom Tool definition, and replicate them in your Pipeline. (And that's just what I find annoying for my use cases, but I don't use all features of Custom Tools; I've never played with "versions", I don't know how they work in a Pipeline context.)

          Thomas de Grenier de Latour added a comment - out of curiosity, what is wrong with just using it via current "tool" step support? Why do we need a custom step for this? Using a Custom Tool from a Pipeline (with " tool ") kind of works; the tool gets installed, and you get back the path to its homedir.  But: if the tool declares extra PATH entries (for instance for a " bin " sub-folder), you must know it, and set the PATH+BLAH accordingly in your " withEnv " wrapper arguments if the tool declares other extra environment variables, you must know it too, and explicitly define them in your Pipeline, again using " withEnv " So basically, you must be aware of some internal details of the Custom Tool definition, and replicate them in your Pipeline. (And that's just what I find annoying for my use cases, but I don't use all features of Custom Tools; I've never played with "versions", I don't know how they work in a Pipeline context.)

            Unassigned Unassigned
            nharniman Nigel Harniman
            Votes:
            21 Vote for this issue
            Watchers:
            32 Start watching this issue

              Created:
              Updated: