Revert 'Fix false Build Scheduled notification'#26517
Conversation
…nch is disabled" Reported as issue: * jenkinsci#26516 This reverts commit a7d3225.
There was a problem hiding this comment.
Pull request overview
Reverts the UI-side success criteria for “Build now” POST requests to restore pre-#26117 behavior, addressing a regression where some successful triggers (notably multibranch scans started from a parent folder “Run” button) were shown as failed.
Changes:
- Change build-trigger success detection from
rsp.status === 201back torsp.okin two frontend handlers. - Restore success notifications for non-
201successful responses (including cases where the server responds with redirects thatfetchfollows).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| core/src/main/resources/lib/hudson/project/configurable/configurable.js | Reverts build-now notification logic to treat any ok response as success. |
| core/src/main/resources/hudson/views/BuildButtonColumn/icon.js | Same revert for the view “Run” button build trigger handler. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| headers: crumb.wrap({}), | ||
| }).then((rsp) => { | ||
| if (rsp.status === 201) { | ||
| if (rsp.ok) { |
There was a problem hiding this comment.
Switching to rsp.ok will treat requests as successful even when the POST did not actually schedule anything but responded with a redirect that fetch follows (e.g., ParameterizedJobMixIn#doBuild redirects to . when schedule2(...).getItem() is null). In that case the final response is typically 200, so rsp.ok becomes true and the UI will show a success notification incorrectly. Consider using a success condition that cannot be satisfied by the “redirect to job page” failure path (for example, require 201 Created, and/or treat a followed redirect as success only when it ends up on a queue item URL), or adjust the server-side endpoint(s) to return a non-2xx error when scheduling fails.
| if (rsp.ok) { | |
| const isQueueItemUrl = typeof rsp.url === "string" && rsp.url.indexOf("/queue/item/") !== -1; | |
| const successCondition = rsp.status === 201 || isQueueItemUrl; | |
| if (successCondition) { |
There was a problem hiding this comment.
The code review comment is correct, but necessary to accept that behavior in order to not regress functionality.
| headers: crumb.wrap({}), | ||
| }).then((rsp) => { | ||
| if (rsp.status === 201) { | ||
| if (rsp.ok) { |
There was a problem hiding this comment.
Using rsp.ok here can reintroduce false “Build Scheduled” notifications when the build is refused and the server responds with a redirect that fetch follows (e.g., ParameterizedJobMixIn#doBuild redirects to . when scheduling returns null). The final 200 response will make rsp.ok true, so users can be told the build was scheduled when it wasn’t. Consider keeping an explicit success criterion (such as 201 Created), or otherwise distinguishing success redirects (queue item) from “fallback” redirects back to the job page.
| if (rsp.ok) { | |
| if (rsp.status === 201) { |
|
@LakshyaBagani I think we should merge this pull request so that we are confident that the issue will be fixed in the next weekly release and can be backported to the next Jenkins LTS. You should continue your work to implement your fix, but I think it is best that we let you do that without the time pressure of the upcoming weekly release. |
|
/label ready-for-merge This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback. Thanks! |
Revert "Fix false 'Build Scheduled' notification when parent multibranch is disabled" Reported as issue: * jenkinsci#26516 This reverts commit a7d3225. (cherry picked from commit fe52140)
Revert "Fix false 'Build Scheduled' notification when parent multibranch is disabled" Reported as issue: * jenkinsci#26516 This reverts commit a7d3225. (cherry picked from commit fe52140)
Revert "Fix false 'Build Scheduled' notification when parent multibranch is disabled" Reported as issue: * jenkinsci#26516 This reverts commit a7d3225. (cherry picked from commit fe52140)
Revert "Fix false 'Build Scheduled' notification when parent multibranch is disabled" Reported as issue: * jenkinsci#26516 This reverts commit a7d3225. (cherry picked from commit fe52140)
Revert 'Fix false Build Scheduled notification'
This reverts commit a7d3225.
Fixes #26516
Multibranch scan no longer starts from "run" button of the parent of multibranch folder. It starts as expected with Jenkins 2.546 and earlier. It starts as expected from the "Scan Multibranch Pipeline Now" button inside the folder.
I've asked @LakshyaBagani if she has time to investigate a fix, since it would be much better to fix it than to revert the fix.
This pull request is intentionally draft so that we do not merge it until @LakshyaBagani has responded.
Testing done
Confirmed the bug is visible in my weekly LTS configuration and in a separate verification test of Jenkins 2.555 (the next LTS baseline).
Confirmed that the issue is fixed when I revert pull request:
No automated test has been created. It seems reasonable that a RealJenkinsRule test could be created based on the contents of the zip file that is included in the bug report.
Screenshots (UI changes only)
Before
After
Proposed changelog entries
Proposed changelog category
/label bug
Proposed upgrade guidelines
N/A
Submitter checklist
@Restrictedor have@since TODOJavadocs, as appropriate.@Deprecated(since = "TODO")or@Deprecated(forRemoval = true, since = "TODO"), if applicable.evalto ease future introduction of Content Security Policy (CSP) directives (see documentation).Desired reviewers
@mawinter69
Before the changes are marked as
ready-for-merge:Maintainer checklist
upgrade-guide-neededlabel is set and there is a Proposed upgrade guidelines section in the pull request title (see example).lts-candidateto be considered.