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

Make Custom Tools compatible with Pipeline

    XMLWordPrintable

    Details

    • Epic Name:
      Custom Tools Compatibility
    • Similar Issues:

      Description

      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.

       

        Attachments

          Issue Links

            Activity

            Hide
            alexbrjo 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')])
            

             

             

            Show
            alexbrjo 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' )])    
            Hide
            imod Dominik Bartholdi added a comment -

            Alex Johnson what would be the syntax in a declarative pipeline?

            Show
            imod Dominik Bartholdi added a comment - Alex Johnson what would be the syntax in a declarative pipeline?
            Hide
            oleg_nenashev 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

            Show
            oleg_nenashev 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
            Hide
            mlasevich 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?

            Show
            mlasevich 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?
            Hide
            tom_gl 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.)

            Show
            tom_gl 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.)

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              nharniman Nigel Harniman
              Votes:
              20 Vote for this issue
              Watchers:
              31 Start watching this issue

                Dates

                Created:
                Updated: