github-starred/gitea-mirror
2
0
Fork 0
mirror of https://github.com/RayLabsHQ/gitea-mirror.git synced 2026-05-07 12:37:43 -05:00
Code Issues 103 Packages Projects Releases 93 Wiki Activity

[GH-ISSUE #264] Release retention limit not enforced during sync (cleanup of old releases not working) #1733

New Issue
Closed
opened 2026-04-27 19:06:08 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-27 19:06:08 -05:00
Owner
Copy Link

Originally created by @sommleon on GitHub (Apr 11, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/264

Description

When using gitea-mirror, it is possible to configure a maximum number of releases to be synced and retained per repository.
However, the expected cleanup behavior does not appear to be working correctly.

Expected behavior

If this limit is configured for release synchronization, then for each repository it should be ensured that the number of synced releases does not exceed the configured maximum. When a new release is synchronized and the limit is already reached, the oldest release in that repository should be automatically removed so that the limit is consistently enforced.

Actual behavior

At least for my instance the configured release retention limit is not consistently enforced. Even though a global limit (in my case 5) is set, repositories often exceed this limit after multiple sync runs. In some cases, repositories contain 7–10 releases instead of the configured maximum. There is no visible error during synchronization, and releases continue to be added without triggering cleanup. Additionally, there is currently no option to manually trigger the cleanup process for releases, which makes it difficult to correct already inconsistent states or to align enforcement of the retention policy.

Originally created by @sommleon on GitHub (Apr 11, 2026). Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/264 **Description** When using gitea-mirror, it is possible to configure a maximum number of releases to be synced and retained per repository. However, the expected cleanup behavior does not appear to be working correctly. **Expected behavior** If this limit is configured for release synchronization, then for each repository it should be ensured that the number of synced releases does not exceed the configured maximum. When a new release is synchronized and the limit is already reached, the oldest release in that repository should be automatically removed so that the limit is consistently enforced. **Actual behavior** At least for my instance the configured release retention limit is not consistently enforced. Even though a global limit (in my case 5) is set, repositories often exceed this limit after multiple sync runs. In some cases, repositories contain 7–10 releases instead of the configured maximum. There is no visible error during synchronization, and releases continue to be added without triggering cleanup. Additionally, there is currently no option to manually trigger the cleanup process for releases, which makes it difficult to correct already inconsistent states or to align enforcement of the retention policy.
GiteaMirror commented 2026-04-27 19:06:10 -05:00
Author
Owner
Copy Link

@arunavo4 commented on GitHub (Apr 13, 2026):

Hey! This should be fixed in #266. Two things were broken:

  1. Release updates were using PUT instead of PATCH, causing silent HTTP 405 errors on every sync
  2. The releaseLimit config only limited how many releases were fetched from GitHub — it never actually cleaned up excess releases on the Gitea side

Both are fixed now. After syncing, the oldest releases beyond your configured limit will be automatically removed.

You can test with the PR image: ghcr.io/raylabshq/gitea-mirror:pr-266

<!-- gh-comment-id:4233881067 --> @arunavo4 commented on GitHub (Apr 13, 2026): Hey! This should be fixed in #266. Two things were broken: 1. Release updates were using `PUT` instead of `PATCH`, causing silent HTTP 405 errors on every sync 2. The `releaseLimit` config only limited how many releases were fetched from GitHub — it never actually cleaned up excess releases on the Gitea side Both are fixed now. After syncing, the oldest releases beyond your configured limit will be automatically removed. You can test with the PR image: `ghcr.io/raylabshq/gitea-mirror:pr-266`
GiteaMirror commented 2026-04-27 19:06:10 -05:00
Author
Owner
Copy Link

@sommleon commented on GitHub (Apr 15, 2026):

Hi, thanks for taking the time to fix this issue. I will test it as ssons as the next stable release is available. :)

<!-- gh-comment-id:4251965492 --> @sommleon commented on GitHub (Apr 15, 2026): Hi, thanks for taking the time to fix this issue. I will test it as ssons as the next stable release is available. :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea-mirror#1733
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?