-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-53358] Remove bogus persistence calls due to notifyListeners #234
base: master
Are you sure you want to change the base?
Conversation
…ance-optimized durability mode
@@ -143,7 +143,8 @@ | |||
<dependency> | |||
<groupId>org.jenkins-ci.plugins.workflow</groupId> | |||
<artifactId>workflow-job</artifactId> | |||
<version>2.21</version> | |||
<!--<version>2.23</version> --> | |||
<version>2.25-rc775.35b435d87ee7</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only until I cut the release, then it will be converted to the final release version and this will be cleaned up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
testNondurableResetsCleanlyPersistedFlag
is failing in the CI build.
testPluginActive
is also failing because the new workflow-job version requires Jenkins 2.73.3 but the baseline here is 2.60.2, so you either need to change the Jenkinsfile here so it doesn't build against 2.60.2, or to bump the baseline here to 2.73.3. I think the latter makes more sense, since otherwise we can't test against the actual baseline, and anyone running this update without the latest version of workflow-job may hit JENKINS-50199 more often so they should probably update both plugins at the same time anyway.
} else if (!(getDurabilityHint().isPersistWithEveryStep()) && !(nodes.stream().anyMatch(x->x instanceof FlowEndNode))) { | ||
// We do not want to invoke gratuitous save calls if we aren't set to persist with every step | ||
// Except that we MUST trigger a persistence call at the very end of the execution | ||
bc.abort(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We aren't worried about whether this causes JENKINS-50199 to happen more often because even if it does, it should only matter when reloading configuration from disk, and that case is now handled by jenkinsci/workflow-job-plugin#104, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dwnusbaum Correct -- and if the cause of JENKINS-50199 is still triggered, then that's a bug somewhere else -- if we were relying on this to trigger persistence, that's a clear bug.
Sigh, looks like some more test flakiness to sort out (AFAICT the hangs are tied to copyLogs, so releasing and incorporating the log-handling rewrite may solve that). |
@joseblas Please could you assist with investigating the test failure here, it seems to relate to https://issues.jenkins-ci.org/browse/JENKINS-34256 and some of the failures described here: https://issues.jenkins-ci.org/browse/JENKINS-50199?focusedCommentId=345572&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345572 and perhaps https://issues.jenkins-ci.org/browse/JENKINS-46507 |
@@ -1441,7 +1441,11 @@ void notifyListeners(List<FlowNode> nodes, boolean synchronous) { | |||
} | |||
} finally { | |||
if (synchronous) { | |||
bc.abort(); // hack to skip save—we are holding a lock | |||
bc.abort(); //// hack to skip save—we are holding a lock |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the introduced //
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to see if people are paying attention
I guess this is on hold? |
JENKINS-53358
These should not be invoked in performance-optimized durability mode -- if we're not trying to save with each step run, we shouldn't do it due to listeners firing. This was an issue that degraded the IO improvements for performance-optimized mode and greatly increased IO calls. The phrase "CD-660" may be meaningful to some here.
Also fixes a buglet noted with the persistedClean flag handling.