-
Bug
-
Resolution: Unresolved
-
Minor
-
Jenkins 2.319.3
Gitea 1.17.1
Gitea Plugin 1.4.1
If a user decides to merge a pull request via rebasing/fast-forward and checks the "Delete branch" checkbox while the Jenkins build of the most recent commit in the pull request is still running, the build fails but Gitea is not notified.
Longer explanation:
When having a pull request open, Gitea can be configured to offer merging the branch via rebase and fast-forwarding, so no explicit branch commit is created. At the same time, Gitea offers a check box to delete a branch after closing the pull request.
If I merge a PR via rebase/fast-forward and choose to delete the branch after merging, and I do all of that while the build of the pull request is still in progress, the Jenkins build of the pull request will fail, but Gitea is apparently not notified about the failure as the icon of the PR will stay the "yellow circle" (build in progress).
See the attached screenshots for an example:
- PR.png shows the PR, which was closed while the build of the most recent commit was still in progress.
- failed_build.png shows the Blue Ocean view of this build.
- pipeline_tail_fail.txt shows the end of the pipeline.log of the failed build. The checkout step seems to fail without Jenkins noticing. Only the subsequent usage of a file in the repo (which is missing, because checkout failed) then causes an error.
- targetbranch.png shows the target branch (master in this case) when clicking on the build status icon ("yellow circle").
- successful_build.png shows the Blue Ocean view of the build triggered by the new commit on master (which has the same hash due to rebase/fast-forward).
- pipeline_tail_successful.txt shows the end of the pipeline.log of the successful build.
- For completeness, I added the Jenkinsfile I used. The "cat readme.md" is just to use some file in the repo and trigger an error if the checkout failed.
Obviously, deleting the branch while a build is in progress is not nice. However, the subsequent build failure should be told to Gitea and you shouldn't end up with an eternal "build in progress" icon. I see two problems here:
- The "checkout" pipeline step fails without Jenkins noticing (it's displayed in green in Blue Ocean). Compare also the two pipeline logs from failed and successful build.
- The build fails (it's red in blue ocean) but Gitea is not notified. As can be seen in pipeline_tail_fail.txt, the part with "[Gitea] Notifying branch build status" is missing.
[JENKINS-69553] Gitea not notified correctly in case PR is merged via rebase/ff and branch gets deleted during PR build
Manuel Mohr
created issue -
Manuel Mohr
made changes -
| Environment |
Original:
Jenkins 2.319.3
Gitea 1.17.1 |
New:
Jenkins 2.319.3
Gitea 1.17.1 Gitea Plugin 1.4.1 |
Manuel Mohr
made changes -
| Description |
Original:
If a user decides to merge a pull request via rebasing/fast-forward and checks the "Delete branch" checkbox _while the Jenkins build of the most recent commit in the pull request is still running,_ I end up with an inconsistent situation that is very confusing to users.
Longer explanation: When having a pull request open, Gitea can be configured to offer merging the branch via rebase and fast-forwarding, so no explicit branch commit is created. At the same time, Gitea offers a check box to delete a branch after closing the pull request. If I merge a PR via rebase/fast-forward and choose to delete the branch after merging, _and_ I do all of that while the build of the pull request is still in progress, the Jenkins build of the pull request will fail, but Gitea is apparently not notified about the failure as the icon of the PR will stay the "yellow circle" (build in progress). At the same time, a new build of the same commit hash will be triggered by the change of the PR's target branch (same commit because rebase/fast-forward was used), which will succeed. However, Gitea will display the "yellow circle" also for the commit on the target branch. Hence, there seem to be two problems: # Gitea is not notified correctly about the build failure of the PR if the PR is closed via rebase/fast-forward while a build is running. # Gitea displays the state of the PR build also for the state of the target branch build, so the target branch build state will never get "green". See the attached screenshots for an example: # PR.png shows the PR, which was closed while the build of the most recent commit was still in progress. # failed_build.png shows the Blue Ocean view of this build. # pipeline_tail_fail.txt shows the end of the pipeline.log of the failed build. The checkout step seems to fail without Jenkins noticing. Only the subsequent usage of a file in the repo (which is missing, because checkout failed) then causes an error. # targetbranch.png shows the target branch (master in this case) when clicking on the build status icon ("yellow circle"). # successful_build.png shows the Blue Ocean view of the build triggered by the new commit on master (which has the same hash due to rebase/fast-forward). # pipeline_tail_successful.txt shows the end of the pipeline.log of the successful build. # For completeness, I added the Jenkinsfile I used. The "cat readme.md" is just to use any file in the repo. Obviously, deleting the branch while a build is in progress is not nice. However, it shouldn't mean that your target branch (which is usually the main development branch) has an eternal "build in progress" icon on it. And it also seems wrong that the "checkout" pipeline step fails without Jenkins noticing. |
New:
If a user decides to merge a pull request via rebasing/fast-forward and checks the "Delete branch" checkbox _while the Jenkins build of the most recent commit in the pull request is still running,_ I end up with an inconsistent situation that is very confusing to users.
Longer explanation: When having a pull request open, Gitea can be configured to offer merging the branch via rebase and fast-forwarding, so no explicit branch commit is created. At the same time, Gitea offers a check box to delete a branch after closing the pull request. If I merge a PR via rebase/fast-forward and choose to delete the branch after merging, _and_ I do all of that while the build of the pull request is still in progress, the Jenkins build of the pull request will fail, but Gitea is apparently not notified about the failure as the icon of the PR will stay the "yellow circle" (build in progress). At the same time, a new build of the same commit hash will be triggered by the change of the PR's target branch (same commit because rebase/fast-forward was used), which will succeed. However, Gitea will display the "yellow circle" also for the commit on the target branch. Hence, there seem to be two problems: # Gitea is not notified correctly about the build failure of the PR if the PR is closed via rebase/fast-forward while a build is running. # Gitea displays the state of the PR build also for the state of the target branch build, so the target branch build state will never get "green". See the attached screenshots for an example: # PR.png shows the PR, which was closed while the build of the most recent commit was still in progress. # failed_build.png shows the Blue Ocean view of this build. # pipeline_tail_fail.txt shows the end of the pipeline.log of the failed build. The checkout step seems to fail without Jenkins noticing. Only the subsequent usage of a file in the repo (which is missing, because checkout failed) then causes an error. # targetbranch.png shows the target branch (master in this case) when clicking on the build status icon ("yellow circle"). # successful_build.png shows the Blue Ocean view of the build triggered by the new commit on master (which has the same hash due to rebase/fast-forward). # pipeline_tail_successful.txt shows the end of the pipeline.log of the successful build. # For completeness, I added the Jenkinsfile I used. The "cat readme.md" is just to use some file in the repo and trigger an error if the checkout failed. Obviously, deleting the branch while a build is in progress is not nice. However, it shouldn't mean that your target branch (which is usually the main development branch) has an eternal "build in progress" icon on it. And it also seems wrong that the "checkout" pipeline step fails without Jenkins noticing. |
Manuel Mohr
made changes -
| Description |
Original:
If a user decides to merge a pull request via rebasing/fast-forward and checks the "Delete branch" checkbox _while the Jenkins build of the most recent commit in the pull request is still running,_ I end up with an inconsistent situation that is very confusing to users.
Longer explanation: When having a pull request open, Gitea can be configured to offer merging the branch via rebase and fast-forwarding, so no explicit branch commit is created. At the same time, Gitea offers a check box to delete a branch after closing the pull request. If I merge a PR via rebase/fast-forward and choose to delete the branch after merging, _and_ I do all of that while the build of the pull request is still in progress, the Jenkins build of the pull request will fail, but Gitea is apparently not notified about the failure as the icon of the PR will stay the "yellow circle" (build in progress). At the same time, a new build of the same commit hash will be triggered by the change of the PR's target branch (same commit because rebase/fast-forward was used), which will succeed. However, Gitea will display the "yellow circle" also for the commit on the target branch. Hence, there seem to be two problems: # Gitea is not notified correctly about the build failure of the PR if the PR is closed via rebase/fast-forward while a build is running. # Gitea displays the state of the PR build also for the state of the target branch build, so the target branch build state will never get "green". See the attached screenshots for an example: # PR.png shows the PR, which was closed while the build of the most recent commit was still in progress. # failed_build.png shows the Blue Ocean view of this build. # pipeline_tail_fail.txt shows the end of the pipeline.log of the failed build. The checkout step seems to fail without Jenkins noticing. Only the subsequent usage of a file in the repo (which is missing, because checkout failed) then causes an error. # targetbranch.png shows the target branch (master in this case) when clicking on the build status icon ("yellow circle"). # successful_build.png shows the Blue Ocean view of the build triggered by the new commit on master (which has the same hash due to rebase/fast-forward). # pipeline_tail_successful.txt shows the end of the pipeline.log of the successful build. # For completeness, I added the Jenkinsfile I used. The "cat readme.md" is just to use some file in the repo and trigger an error if the checkout failed. Obviously, deleting the branch while a build is in progress is not nice. However, it shouldn't mean that your target branch (which is usually the main development branch) has an eternal "build in progress" icon on it. And it also seems wrong that the "checkout" pipeline step fails without Jenkins noticing. |
New:
If a user decides to merge a pull request via rebasing/fast-forward and checks the "Delete branch" checkbox _while the Jenkins build of the most recent commit in the pull request is still running,_ the build fails but Gitea is not notified.
Longer explanation: When having a pull request open, Gitea can be configured to offer merging the branch via rebase and fast-forwarding, so no explicit branch commit is created. At the same time, Gitea offers a check box to delete a branch after closing the pull request. If I merge a PR via rebase/fast-forward and choose to delete the branch after merging, _and_ I do all of that while the build of the pull request is still in progress, the Jenkins build of the pull request will fail, but Gitea is apparently not notified about the failure as the icon of the PR will stay the "yellow circle" (build in progress). See the attached screenshots for an example: # PR.png shows the PR, which was closed while the build of the most recent commit was still in progress. # failed_build.png shows the Blue Ocean view of this build. # pipeline_tail_fail.txt shows the end of the pipeline.log of the failed build. The checkout step seems to fail without Jenkins noticing. Only the subsequent usage of a file in the repo (which is missing, because checkout failed) then causes an error. # targetbranch.png shows the target branch (master in this case) when clicking on the build status icon ("yellow circle"). # successful_build.png shows the Blue Ocean view of the build triggered by the new commit on master (which has the same hash due to rebase/fast-forward). # pipeline_tail_successful.txt shows the end of the pipeline.log of the successful build. # For completeness, I added the Jenkinsfile I used. The "cat readme.md" is just to use some file in the repo and trigger an error if the checkout failed. Obviously, deleting the branch while a build is in progress is not nice. However, the subsequent build failure should be told to Gitea and you shouldn't end up with an eternal "build in progress" icon. I see two problems here: # The "checkout" pipeline step fails without Jenkins noticing (it's displayed in green in Blue Ocean). # The build fails (it's red in blue ocean) but Gitea is not notified. As can be seen in pipeline_tail_fail.txt, the part with "[Gitea] Notifying branch build status" is missing. |
| Summary | Original: Weird behavior in case PR is merged via rebase/ff and branch gets deleted during PR build | New: Gitea not notified correctly in case PR is merged via rebase/ff and branch gets deleted during PR build |
Manuel Mohr
made changes -
| Description |
Original:
If a user decides to merge a pull request via rebasing/fast-forward and checks the "Delete branch" checkbox _while the Jenkins build of the most recent commit in the pull request is still running,_ the build fails but Gitea is not notified.
Longer explanation: When having a pull request open, Gitea can be configured to offer merging the branch via rebase and fast-forwarding, so no explicit branch commit is created. At the same time, Gitea offers a check box to delete a branch after closing the pull request. If I merge a PR via rebase/fast-forward and choose to delete the branch after merging, _and_ I do all of that while the build of the pull request is still in progress, the Jenkins build of the pull request will fail, but Gitea is apparently not notified about the failure as the icon of the PR will stay the "yellow circle" (build in progress). See the attached screenshots for an example: # PR.png shows the PR, which was closed while the build of the most recent commit was still in progress. # failed_build.png shows the Blue Ocean view of this build. # pipeline_tail_fail.txt shows the end of the pipeline.log of the failed build. The checkout step seems to fail without Jenkins noticing. Only the subsequent usage of a file in the repo (which is missing, because checkout failed) then causes an error. # targetbranch.png shows the target branch (master in this case) when clicking on the build status icon ("yellow circle"). # successful_build.png shows the Blue Ocean view of the build triggered by the new commit on master (which has the same hash due to rebase/fast-forward). # pipeline_tail_successful.txt shows the end of the pipeline.log of the successful build. # For completeness, I added the Jenkinsfile I used. The "cat readme.md" is just to use some file in the repo and trigger an error if the checkout failed. Obviously, deleting the branch while a build is in progress is not nice. However, the subsequent build failure should be told to Gitea and you shouldn't end up with an eternal "build in progress" icon. I see two problems here: # The "checkout" pipeline step fails without Jenkins noticing (it's displayed in green in Blue Ocean). # The build fails (it's red in blue ocean) but Gitea is not notified. As can be seen in pipeline_tail_fail.txt, the part with "[Gitea] Notifying branch build status" is missing. |
New:
If a user decides to merge a pull request via rebasing/fast-forward and checks the "Delete branch" checkbox _while the Jenkins build of the most recent commit in the pull request is still running,_ the build fails but Gitea is not notified.
Longer explanation: When having a pull request open, Gitea can be configured to offer merging the branch via rebase and fast-forwarding, so no explicit branch commit is created. At the same time, Gitea offers a check box to delete a branch after closing the pull request. If I merge a PR via rebase/fast-forward and choose to delete the branch after merging, _and_ I do all of that while the build of the pull request is still in progress, the Jenkins build of the pull request will fail, but Gitea is apparently not notified about the failure as the icon of the PR will stay the "yellow circle" (build in progress). See the attached screenshots for an example: # PR.png shows the PR, which was closed while the build of the most recent commit was still in progress. # failed_build.png shows the Blue Ocean view of this build. # pipeline_tail_fail.txt shows the end of the pipeline.log of the failed build. The checkout step seems to fail without Jenkins noticing. Only the subsequent usage of a file in the repo (which is missing, because checkout failed) then causes an error. # targetbranch.png shows the target branch (master in this case) when clicking on the build status icon ("yellow circle"). # successful_build.png shows the Blue Ocean view of the build triggered by the new commit on master (which has the same hash due to rebase/fast-forward). # pipeline_tail_successful.txt shows the end of the pipeline.log of the successful build. # For completeness, I added the Jenkinsfile I used. The "cat readme.md" is just to use some file in the repo and trigger an error if the checkout failed. Obviously, deleting the branch while a build is in progress is not nice. However, the subsequent build failure should be told to Gitea and you shouldn't end up with an eternal "build in progress" icon. I see two problems here: # The "checkout" pipeline step fails without Jenkins noticing (it's displayed in green in Blue Ocean). Compare also the two pipeline logs from failed and successful build. # The build fails (it's red in blue ocean) but Gitea is not notified. As can be seen in pipeline_tail_fail.txt, the part with "[Gitea] Notifying branch build status" is missing. |