[Feature] Auto-lock PR Conversations When Merged #9970

New Issue

GiteaMirror · 2025-11-02T08:54:38-06:00

GiteaMirror commented

2025-11-02 08:54:38 -06:00

Originally created by @kdumontnu on GitHub (Dec 13, 2022).

Feature Description

I think it would be helpful if repos had a setting to automatically lock a conversation when an issue is closed and/or PR is merged.

Related to: https://github.com/go-gitea/gitea/issues/20012

Screenshots

No response

Originally created by @kdumontnu on GitHub (Dec 13, 2022). ### Feature Description I think it would be helpful if repos had a setting to automatically lock a conversation when an issue is closed and/or PR is merged. Related to: https://github.com/go-gitea/gitea/issues/20012 ### Screenshots _No response_

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:54:38 -06:00

GiteaMirror commented

2025-11-02 08:54:39 -06:00

@delvh commented on GitHub (Dec 13, 2022):

Wouldn't it be better to let a CI do that?
Then we don't have a weird edge case that is only sometimes wanted in our core while still providing the functionality…
As far as I know, the CI currently proposed should (later on) be able to do that (see #21937)

@delvh commented on GitHub (Dec 13, 2022): Wouldn't it be better to let a CI do that? Then we don't have a weird edge case that is only sometimes wanted in our core while still providing the functionality… As far as I know, the CI currently proposed should (later on) be able to do that (see #21937)

GiteaMirror commented

2025-11-02 08:54:39 -06:00

@kdumontnu commented on GitHub (Dec 14, 2022):

Wouldn't it be better to let a CI do that? Then we don't have a weird edge case that is only sometimes wanted in our core while still providing the functionality… As far as I know, the CI currently proposed should (later on) be able to do that (see #21937)

Yeah, I appreciate your point, but CI seems like overkill for this if a user isn't already running CI for something else (also, is there a webhook for issues closed or would the CI job it have to poll each open issue?). It seems like what you suggest is the strategy GitHub has taken, as there doesn't seem to be a feature like this built in. From a UX perspective, it seems like like a nice compliment to auto-merge.

If this really is a niche feature that a majority of users don't want/need, I agree it should go to CI. If a reasonable number of folks want this it would be nice to build into the UI. I'll post in discord and see if other people would like this feature, and if there's not much traction in a week then I'm perfectly happy closing this.

@kdumontnu commented on GitHub (Dec 14, 2022): > Wouldn't it be better to let a CI do that? Then we don't have a weird edge case that is only sometimes wanted in our core while still providing the functionality… As far as I know, the CI currently proposed should (later on) be able to do that (see #21937) Yeah, I appreciate your point, but CI seems like overkill for this if a user isn't already running CI for something else (also, is there a webhook for issues closed or would the CI job it have to poll each open issue?). It seems like what you suggest is the [strategy GitHub has taken](https://github.com/dessant/lock-threads), as there doesn't seem to be a feature like this built in. From a UX perspective, it seems like like a nice compliment to auto-merge. If this really is a niche feature that a majority of users don't want/need, I agree it should go to CI. If a reasonable number of folks want this it would be nice to build into the UI. I'll post in discord and see if other people would like this feature, and if there's not much traction in a week then I'm perfectly happy closing this.

GiteaMirror commented

2025-11-02 08:54:39 -06:00

@jolheiser commented on GitHub (Dec 14, 2022):

also, is there a webhook for issues closed or would the CI job it have to poll each open issue?

Yes-ish, the base issues covers "Issue opened, closed, reopened, or edited."
The job would need to check if it was closed specifically, but the event would come across.

@jolheiser commented on GitHub (Dec 14, 2022): > also, is there a webhook for issues closed or would the CI job it have to poll each open issue? Yes-ish, the base `issues` covers "Issue opened, closed, reopened, or edited." The job would need to check if it was closed specifically, but the event would come across.

GiteaMirror commented

2025-11-02 08:54:39 -06:00

@lunny commented on GitHub (Dec 14, 2022):

Wouldn't it be better to let a CI do that? Then we don't have a weird edge case that is only sometimes wanted in our core while still providing the functionality… As far as I know, the CI currently proposed should (later on) be able to do that (see #21937)

Yeah, I appreciate your point, but CI seems like overkill for this if a user isn't already running CI for something else (also, is there a webhook for issues closed or would the CI job it have to poll each open issue?). It seems like what you suggest is the strategy GitHub has taken, as there doesn't seem to be a feature like this built in. From a UX perspective, it seems like like a nice compliment to auto-merge.

If this really is a niche feature that a majority of users don't want/need, I agree it should go to CI. If a reasonable number of folks want this it would be nice to build into the UI. I'll post in discord and see if other people would like this feature, and if there's not much traction in a week then I'm perfectly happy closing this.

That Action could be reused when Gitea Actions PR merged.

@lunny commented on GitHub (Dec 14, 2022): > > Wouldn't it be better to let a CI do that? Then we don't have a weird edge case that is only sometimes wanted in our core while still providing the functionality… As far as I know, the CI currently proposed should (later on) be able to do that (see #21937) > > Yeah, I appreciate your point, but CI seems like overkill for this if a user isn't already running CI for something else (also, is there a webhook for issues closed or would the CI job it have to poll each open issue?). It seems like what you suggest is the [strategy GitHub has taken](https://github.com/dessant/lock-threads), as there doesn't seem to be a feature like this built in. From a UX perspective, it seems like like a nice compliment to auto-merge. > > If this really is a niche feature that a majority of users don't want/need, I agree it should go to CI. If a reasonable number of folks want this it would be nice to build into the UI. I'll post in discord and see if other people would like this feature, and if there's not much traction in a week then I'm perfectly happy closing this. That Action could be reused when Gitea Actions PR merged.

GiteaMirror commented

2025-11-02 08:54:40 -06:00

@a1012112796 commented on GitHub (Dec 15, 2022):

How about add an extern option to do it ?

the quick_actions in gitlab looks also good.

@a1012112796 commented on GitHub (Dec 15, 2022): How about add an extern option to do it ? ![屏幕截图 2022-12-14 170346](https://user-images.githubusercontent.com/25342410/207742844-35b07f34-2911-4896-a85d-5a1915eb2aa5.png) the [quick_actions](https://docs.gitlab.com/ee/user/project/quick_actions.html) in gitlab looks also good.

GiteaMirror commented

2025-11-02 08:54:40 -06:00

@lunny commented on GitHub (May 7, 2024):

Not a good idea to put more and more checkboxes/buttons there.

@lunny commented on GitHub (May 7, 2024): Not a good idea to put more and more checkboxes/buttons there.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9970