|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
basic-steps/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java
basic-steps/src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java
cps/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsBodyExecution.java
cps/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsBodyInvoker.java
cps/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsBodySubContext.java
cps/src/main/java/org/jenkinsci/plugins/workflow/cps/DSL.java
cps/src/main/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStep.java
cps/src/main/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStepExecution.java
step-api/src/main/java/org/jenkinsci/plugins/workflow/steps/BodyExecution.java
step-api/src/main/java/org/jenkinsci/plugins/workflow/steps/BodyExecutionCallback.java
step-api/src/main/java/org/jenkinsci/plugins/workflow/steps/BodyInvoker.java
support/src/main/java/org/jenkinsci/plugins/workflow/support/steps/ExecutorStepExecution.java
support/src/main/java/org/jenkinsci/plugins/workflow/support/steps/WorkspaceStepExecution.java
support/src/test/java/org/jenkinsci/plugins/workflow/test/steps/BlockSemaphoreStep.java
support/src/test/java/org/jenkinsci/plugins/workflow/test/steps/TmpDirStepExecution.java
http://jenkins-ci.org/commit/workflow-plugin/62b92d7a563fcb7a20d5b0aa69058de5be120b8c
Log:
JENKINS-25504
Introducing BodyExecutionCallback as a beefed up version of
FutureCallback, so that the step implementation can interact with the
start body block / end body block, such as adding log messages.
We do this by creating a different StepContext objects that are only
valid during the body start and body end. This in turn allow Steps to
re-inject the context to access correct TaskListeners and things like
that (which is not in this commit.)
Copying my email to jenkinsci-dev for the motivation:
------
I'm working on this card, where we want to be able to write to console
log and do stuff at the end of the body invocation.
The challenge here is that the Step API has no dependency to the
workflow Flow Node API (it goes the other way around), so we need to do
this in a way that doesn't force Flow API into the likes of RetryStep.
That pretty much means we need to do the context injection of
TaskListener like StepContext does.
I thought about two ways to do this.
One is to reuse the existing StepContext instance. We could just say
that at the point of the callback from the body execution,
StepContet.get() would return the context objects for the end of the
body (TaskListener connecte to the right FlowNode, etc.) We could then
provide some convenience base class that performs @StepContextParameter
injection, so that everything gets reinjected.
This works, but I also feel that it's bit brittle, especially for
ParallelStep that invokes multiple bodies at the same time, and thus it
wants multiple different post body execution context. So I started
thinking about another way, where the end of the body execution is
notified to FutureCallback<BodyExecutionResult> instead of
FutureCallback<Object>, and the newly added BodyExecutionResult class
would have properties like outcome, the same get(Class) method that
returns contextual object, and so on.
That also makes it more explicit that the context injection works
differently post body execution.