When a pull request merged, base repository's all PR's status will be checking #4510

Closed
opened 2025-11-02 05:53:05 -06:00 by GiteaMirror · 5 comments
Owner

Originally created by @lunny on GitHub (Dec 18, 2019).

I think we missed checkAndUpdateStatus(pr) on services/pull/check.go:193.

 pr, err := models.GetPullRequestByID(id)
			if err != nil {
				log.Error("GetPullRequestByID[%s]: %v", prID, err)
				continue
			} else if manuallyMerged(pr) {
-                              continue
			} else if err = TestPatch(pr); err != nil {
				log.Error("testPatch[%d]: %v", pr.ID, err)
-                              continue
			}
			checkAndUpdateStatus(pr)
图片
Originally created by @lunny on GitHub (Dec 18, 2019). I think we missed `checkAndUpdateStatus(pr)` on `services/pull/check.go:193`. ```diff pr, err := models.GetPullRequestByID(id) if err != nil { log.Error("GetPullRequestByID[%s]: %v", prID, err) continue } else if manuallyMerged(pr) { - continue } else if err = TestPatch(pr); err != nil { log.Error("testPatch[%d]: %v", pr.ID, err) - continue } checkAndUpdateStatus(pr) ``` <img width="1038" alt="图片" src="https://user-images.githubusercontent.com/81045/71085312-27a20600-21d2-11ea-9654-fa1ec09fdeb6.png">
GiteaMirror added the type/bug label 2025-11-02 05:53:05 -06:00
Author
Owner

@zeripath commented on GitHub (Dec 19, 2019):

Hmm it's weird because that would be a change from the previous logic AFAIU. I think I will have to take another look.

Sorry for adding this bug

@zeripath commented on GitHub (Dec 19, 2019): Hmm it's weird because that would be a change from the previous logic AFAIU. I think I will have to take another look. Sorry for adding this bug
Author
Owner

@zeripath commented on GitHub (Dec 19, 2019):

So I'm confused - this shouldn't happen. @lunny is it just that you have to wait a bit longer?

manuallyMerged() will check if it can find a merge commit appropriate for the PR and if so will set the pr.Status to ManuallyMerged. If it returns true it will update the status. If it returns false then TestPatch will run.

Now the only way that the status will remain in Status Checking is if TestPatch subsequently throws an error.

Do you have any logs so that we can see where the issue is?

I guess it would be reasonable to skip TestPatch if the status is set to ManuallyMerged by manuallyMerged even if it returns false?

@zeripath commented on GitHub (Dec 19, 2019): So I'm confused - this shouldn't happen. @lunny is it just that you have to wait a bit longer? `manuallyMerged()` will check if it can find a merge commit appropriate for the PR and if so will set the pr.Status to ManuallyMerged. If it returns true it will update the status. If it returns false then TestPatch will run. Now the only way that the status will remain in Status Checking is if TestPatch subsequently throws an error. Do you have any logs so that we can see where the issue is? I guess it would be reasonable to skip TestPatch if the status is set to ManuallyMerged by manuallyMerged even if it returns false?
Author
Owner

@lunny commented on GitHub (Dec 19, 2019):

@zeripath I cannot find that repository again. Maybe it spent too long time to do that. Assume a base repository has 200 PRs.

@lunny commented on GitHub (Dec 19, 2019): @zeripath I cannot find that repository again. Maybe it spent too long time to do that. Assume a base repository has 200 PRs.
Author
Owner

@zeripath commented on GitHub (Dec 19, 2019):

Once queues are merged we can let this thing have a dynamically growing worker pool.

@zeripath commented on GitHub (Dec 19, 2019): Once queues are merged we can let this thing have a dynamically growing worker pool.
Author
Owner

@lunny commented on GitHub (Dec 20, 2019):

I just close this now.

@lunny commented on GitHub (Dec 20, 2019): I just close this now.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4510