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

Ability to mark a SimpleBuildStep as not requiring a workspace context

    • jenkins 2.258, workflow-basic-steps 2.22

      Currently SimpleBuildStep expects to be passed a valid FilePath workspace, limiting its use in Pipelines to step appearing inside a node block. This is because BuildStep historically ran in an AbstractBuild which always has a workspace. But there are many build steps, especially Publisher but sometimes also Builder, which do not actually use the workspace (or node) at all, and these are needlessly blocked from being used outside a node block.

      Would be useful to have a SimpleBuildStepDescriptor defining a method which would allow an implementation to declare that the workspace and launcher parameters to perform may be null. CoreStep would then be able to run in any context, passing those parameters only if the StepContext defined them.

      SimpleBuildWrapper could potentially benefit from a similar API. This would have been useful for TimestamperBuildWrapper, avoiding the need for a separate TimestamperStep.

          [JENKINS-46175] Ability to mark a SimpleBuildStep as not requiring a workspace context

          OK, then that should not be too hard. I'd be inclined towards extra default interface methods (needsFilePath() and needsLauncher() come to mind). A SimpleBuildStepDescriptor would need to be an interface too, and would be trickier to integrate.

          Tim Van Holder added a comment - OK, then that should not be too hard. I'd be inclined towards extra default interface methods ( needsFilePath() and needsLauncher() come to mind). A SimpleBuildStepDescriptor would need to be an interface too, and would be trickier to integrate.

          Jesse Glick added a comment -

          You should not need separate markers for FilePath and Launcher—if you are inside node you will get both, otherwise you will get neither.

          Jesse Glick added a comment - You should not need separate markers for FilePath and Launcher —if you are inside node you will get both, otherwise you will get neither.

          If that's guaranteed (now and in the future). then I suppose a single method like requiresNode() or isNodeSpecific() might make sense. Would have to see if there's similar methods elsewhere that I can reuse the name of.

          Tim Van Holder added a comment - If that's guaranteed (now and in the future). then I suppose a single method like requiresNode() or isNodeSpecific() might make sense. Would have to see if there's similar methods elsewhere that I can reuse the name of.

          Jesse Glick added a comment -

          or requiresWorkspace

          Jesse Glick added a comment - or requiresWorkspace

          Draft PR for jenkins core added.
          I went with 2 separate predicates (requiresWorkspace() and requiresLauncher()) for maximum flexibility.

          Changes made to both SimpleBuildStep and SimpleBuildWrapper (plus the latter's nested Disposer).
          Will see what that means for CoreStep and the like once I have an incremental to play with.

          Tim Van Holder added a comment - Draft PR for jenkins core added. I went with 2 separate predicates ( requiresWorkspace() and requiresLauncher() ) for maximum flexibility. Changes made to both SimpleBuildStep and SimpleBuildWrapper (plus the latter's nested Disposer ). Will see what that means for CoreStep and the like once I have an incremental to play with.

          Jesse Glick added a comment -

          once I have an incremental to play with

          Note that for purposes of local development you can simply mvn -DskipTests clean install from core and then set jenkins.version to 2.XXX-SNAPSHOT in your plugin POM. IDEs with proper Maven support will also interpret this to mean that core + plugin are effectively part of a single build tree, so you can refactor across the two, make a core change and run a fast JUnit test from the plugin to verify it, etc.

          Jesse Glick added a comment - once I have an incremental to play with Note that for purposes of local development you can simply mvn -DskipTests clean install from core and then set jenkins.version to 2.XXX-SNAPSHOT in your plugin POM. IDEs with proper Maven support will also interpret this to mean that core + plugin are effectively part of a single build tree, so you can refactor across the two, make a core change and run a fast JUnit test from the plugin to verify it, etc.

          Daniel Beck added a comment -

          Is this done?

          Daniel Beck added a comment - Is this done?

          Tim Van Holder added a comment - - edited

          The API on the core side is now there, but the ticket won't be resolved until workflow-basic-steps uses it.
          I'll link to that PR too.

          Tim Van Holder added a comment - - edited The API on the core side is now there, but the ticket won't be resolved until workflow-basic-steps uses it. I'll link to that PR too.

          Both PRs now merged.

          Will set as Resolved once workflow-basic-steps 2.22 is released.

          Tim Van Holder added a comment - Both PRs now merged. Will set as Resolved once workflow-basic-steps 2.22 is released.

          Mark Waite added a comment -

          Workflow basic steps plugin 2.22 released Oct 1, 2020

          Mark Waite added a comment - Workflow basic steps plugin 2.22 released Oct 1, 2020

            zastai Tim Van Holder
            jglick Jesse Glick
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: