Skip to content

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

Closed

Description

@jenkins-infra-bot

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.


Originally reported by jglick, imported from: Ability to mark a SimpleBuildStep as not requiring a workspace context
  • assignee: zastai
  • status: Closed
  • priority: Major
  • component(s): core, workflow-basic-steps-plugin
  • label(s): api, pipeline
  • resolution: Fixed
  • resolved: 2020-10-02T17:04:43+00:00
  • votes: 2
  • watchers: 4
  • imported: 2025-11-24
Raw content of original issue

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.

Activity

  1. jenkins-infra-bot commented on Aug 14, 2017

    @jenkins-infra-bot
    Author
  2. jenkins-infra-bot commented on Jun 22, 2018

    @jenkins-infra-bot
    Author
    jglick:
    • Original comment link
    • Raw content of original comment:

      If SimpleBuildWrapper is updated, then this code should also be expanded to permit such wrappers to be used in Declarative options blocks.

    If SimpleBuildWrapper is updated, then this code should also be expanded to permit such wrappers to be used in Declarative options blocks.

  3. jenkins-infra-bot commented on Jun 2, 2020

    @jenkins-infra-bot
    Author
    zastai:

    Will try to give this a look after JENKINS-29144 is done.

  4. jenkins-infra-bot commented on Jun 6, 2020

    @jenkins-infra-bot
    Author
    zastai:
    • Original comment link
    • Raw content of original comment:

      So if CoreStep no longer lists FilePath and Launcher as required, then it would happily wrap a SimpleBuildStep that says it needs one or both of those, wouldn't it? With an error only produced at execution time?

    So if CoreStep no longer lists FilePath and Launcher as required, then it would happily wrap a SimpleBuildStep that says it needs one or both of those, wouldn't it? With an error only produced at execution time?

  5. jenkins-infra-bot commented on Jun 8, 2020

    @jenkins-infra-bot
    Author
    jglick:

    Yes the error would only be produced at runtime (according to whatever flag is mechanism is chosen—I suggested a method in a new SimpleBuildStepDescriptor but maybe you could use a new default method), but that is already the case. It just means that rather than this being enforced by getRequiredContext and thus MissingContextVariableException being thrown automatically by checkContextAvailability from DSL right before the step is started, the exception will be thrown from CoreStep.Execution if the step says it needs a workspace yet none was in fact provided. https://github.com/jenkinsci/credentials-binding-plugin/blob/9bed48e5b36820cc1d2f8053965eb37bb18a6f17/src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep.java#L131-L134 is a good example.

  6. jenkins-infra-bot commented on Jun 8, 2020

    @jenkins-infra-bot
    Author
    zastai:
    • Original comment link
    • Raw content of original 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.

    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.

  7. jenkins-infra-bot commented on Jun 8, 2020

    @jenkins-infra-bot
    Author
    jglick:
    • Original comment link
    • Raw content of original 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.

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

  8. jenkins-infra-bot commented on Jun 8, 2020

    @jenkins-infra-bot
    Author
    zastai:
    • Original comment link
    • Raw content of original 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.

    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.

  9. jenkins-infra-bot commented on Jun 9, 2020

    @jenkins-infra-bot
    Author
    jglick:
    • Original comment link
    • Raw content of original comment:

      or requiresWorkspace

    or requiresWorkspace

  10. jenkins-infra-bot commented on Jun 13, 2020

    @jenkins-infra-bot
    Author
    zastai:
    • Original comment link
    • Raw content of original 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.

    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.

  11. jenkins-infra-bot commented on Jun 15, 2020

    @jenkins-infra-bot
    Author
    jglick:
    • Original comment link
    • Raw content of original 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.

    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.

  12. jenkins-infra-bot commented on Oct 1, 2020

    @jenkins-infra-bot
    Author
    danielbeck:
    • Original comment link
    • Raw content of original comment:

      Is this done?

    Is this done?

  13. jenkins-infra-bot commented on Oct 1, 2020

    @jenkins-infra-bot
    Author
    zastai:
    • Original comment link
    • Raw content of original comment:

      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.

    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.

  14. jenkins-infra-bot commented on Oct 1, 2020

    @jenkins-infra-bot
    Author
    zastai:
    • Original comment link
    • Raw content of original comment:

      Both PRs now merged.

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

    Both PRs now merged.

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

  15. jenkins-infra-bot commented on Oct 17, 2020

    @jenkins-infra-bot
    Author
    markewaite:
    • Original comment link
    • Raw content of original comment:

      Workflow basic steps plugin 2.22 released Oct 1, 2020

    Workflow basic steps plugin 2.22 released Oct 1, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions