Skip to content

[JENKINS-41854] Recontextualizing FilePath on demand#101

Merged
dwnusbaum merged 12 commits into
jenkinsci:masterfrom
jglick:DynamicContext-JENKINS-41854
Jun 3, 2019
Merged

[JENKINS-41854] Recontextualizing FilePath on demand#101
dwnusbaum merged 12 commits into
jenkinsci:masterfrom
jglick:DynamicContext-JENKINS-41854

Conversation

@jglick

@jglick jglick commented Mar 29, 2019

Copy link
Copy Markdown
Member

@jglick
jglick requested a review from basil March 29, 2019 01:16
@jglick

jglick commented Mar 29, 2019

Copy link
Copy Markdown
Member Author

Our Windows agents are very flaky…

@jglick jglick closed this Mar 29, 2019
@jglick jglick reopened this Mar 29, 2019
jglick added 2 commits March 28, 2019 22:03
A static contextual object in a nested scope does not override a DynamicContext in a parent scope.
In this case we actually did want to have WorkspaceStepExecution use DynamicContext for the same JENKINS-41854 fix,
but are there other cases where this is a real flaw?
…ilePathAfterAgentReconnection in which the build fails due to a ChannelClosedException but unclear where this is actually being thrown up (and am not currently succeeding in reproducing).
@jglick
jglick requested a review from dwnusbaum April 8, 2019 17:03

@basil basil left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing this long-standing robustness bug!

@dwnusbaum

Copy link
Copy Markdown
Member

Also looks like we need to bump to plugin-pom 3.43 to fix the Javadoc failures.

@jglick

jglick commented May 31, 2019

Copy link
Copy Markdown
Member Author

bump to plugin-pom 3.43

Sure, I can do a round of updates.

protected FilePath tryResolve() {
return FilePathUtils.find(slave, path);
}
@Override protected FlowExecutionOwner getOwner() {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this for?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was actually introduced for use from PickleDynamicContext, which was removed as of 5a7a0b2, but it is independently useful—means that if a program is still using FilePathPickle despite this PR + jenkinsci/workflow-basic-steps-plugin#86, and it is taking a while to resume, the build log will indicate why. Previously only ExecutorPickle implemented this. Generally pickles should implement this method if possible.

@jglick

jglick commented May 31, 2019

Copy link
Copy Markdown
Member Author

On hold as in jenkinsci/workflow-support-plugin#95 (comment).

@jglick
jglick requested a review from dwnusbaum June 1, 2019 13:53
@dwnusbaum
dwnusbaum merged commit 821e21a into jenkinsci:master Jun 3, 2019
@dwnusbaum

Copy link
Copy Markdown
Member

@jglick If someone updates to the new version of workflow-durable-task-step without also updating workflow-cps, things will totally break, since there won't be a FilePath in the context and FilePathDynamicContext won't actually be used, right?

I was thinking we might be able to fix this by adding a FilePath in addition to FilePathRepresentation, but over in workflow-cps actual context variables take precedence over a DynamicContext at the same scope, so that would mean FilePathRepresentation would never be used.

Does this seem like something we should look into, or do you think a warning in the release notes is enough?

@jglick

jglick commented Jun 3, 2019

Copy link
Copy Markdown
Member Author

I think it just needs to be release-noted. The Jenkins update center has no general way of dealing with this. Advertisement for Beekeeper I suppose.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants