[pull] main from go-gitea:main #57
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
user should be a collaborator of the base repo to create a PR
- Change condition to include `RepoID` equal to 0 for organization secrets --------- Signed-off-by: Bo-Yi Wu <[email protected]> Co-authored-by: Giteabot <[email protected]>
There's already `initActionsTasks`; it will avoid additional check for if Actions enabled to move `registerActionsCleanup` into it. And we don't really need `OlderThanConfig`.
Fix #30156 (comment) Forgot fixing it in #31719
Before: <img width="1641" alt="image" src="https://github.com/user-attachments/assets/60fa3f3e-cf19-4903-b080-616aef28057b"> After: <img width="1674" alt="image" src="https://github.com/user-attachments/assets/b04fd01e-838d-45c3-9655-cb39a2f7d1f2">
…ion (#31702) Fix #31137. Replace #31623 #31697. When migrating LFS objects, if there's any object that failed (like some objects are losted, which is not really critical), Gitea will stop migrating LFS immediately but treat the migration as successful. This PR checks the error according to the [LFS api doc](https:https://github.com/git-lfs/git-lfs/blob/main/docs/api/batch.md#successful-responses). > LFS object error codes should match HTTP status codes where possible: > > - 404 - The object does not exist on the server. > - 409 - The specified hash algorithm disagrees with the server's acceptable options. > - 410 - The object was removed by the owner. > - 422 - Validation error. If the error is `404`, it's safe to ignore it and continue migration. Otherwise, stop the migration and mark it as failed to ensure data integrity of LFS objects. And maybe we should also ignore others errors (maybe `410`? I'm not sure what's the difference between "does not exist" and "removed by the owner".), we can add it later when some users report that they have failed to migrate LFS because of an error which should be ignored.
Resolve #31566. Updates to protected branches often come from PR merges, and they are unlikely to be used to create new PRs. <img width="1346" alt="image" src="https://github.com/user-attachments/assets/9ed72bd6-0303-435d-856c-184784104c6a"> <img width="1347" alt="image" src="https://github.com/user-attachments/assets/c1a1df4b-1c16-4116-aea3-d452242119e0"> <img width="1336" alt="image" src="https://github.com/user-attachments/assets/706034ad-d3c3-4853-a6b8-cbaf87c70ba0">
Fix #31707. Also related to #31715. Some Actions resources could has different types of ownership. It could be: - global: all repos and orgs/users can use it. - org/user level: only the org/user can use it. - repo level: only the repo can use it. There are two ways to distinguish org/user level from repo level: 1. `{owner_id: 1, repo_id: 2}` for repo level, and `{owner_id: 1, repo_id: 0}` for org level. 2. `{owner_id: 0, repo_id: 2}` for repo level, and `{owner_id: 1, repo_id: 0}` for org level. The first way seems more reasonable, but it may not be true. The point is that although a resource, like a runner, belongs to a repo (it can be used by the repo), the runner doesn't belong to the repo's org (other repos in the same org cannot use the runner). So, the second method makes more sense. And the first way is not user-friendly to query, we must set the repo id to zero to avoid wrong results. So, #31715 should be right. And the most simple way to fix #31707 is just: ```diff - shared.GetRegistrationToken(ctx, ctx.Repo.Repository.OwnerID, ctx.Repo.Repository.ID) + shared.GetRegistrationToken(ctx, 0, ctx.Repo.Repository.ID) ``` However, it is quite intuitive to set both owner id and repo id since the repo belongs to the owner. So I prefer to be compatible with it. If we get both owner id and repo id not zero when creating or finding, it's very clear that the caller want one with repo level, but set owner id accidentally. So it's OK to accept it but fix the owner id to zero.
Fix #31657. According to the [doc](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onschedule) of GitHub Actions, The timezone for cron should be UTC, not the local timezone. And Gitea Actions doesn't have any reasons to change this, so I think it's a bug. However, Gitea Actions has extended the syntax, as it supports descriptors like `@weekly` and `@every 5m`, and supports specifying the timezone like `TZ=UTC 0 10 * * *`. So we can make it use UTC only when the timezone is not specified, to be compatible with GitHub Actions, and also respect the user's specified. It does break the feature because the times to run tasks would be changed, and it may confuse users. So I don't think we should backport this. ##⚠️ BREAKING⚠️ If the server's local time zone is not UTC, a scheduled task would run at a different time after upgrading Gitea to this version.
The "false" value was not handled correctly, it would cause bugs in the future (fortunately, this behavior is not used in code yet).
Part of #24256. Clear up old action logs to free up storage space. Users will see a message indicating that the log has been cleared if they view old tasks. <img width="1361" alt="image" src="https://github.com/user-attachments/assets/9f0f3a3a-bc5a-402f-90ca-49282d196c22"> Docs: https://gitea.com/gitea/docs/pulls/40 --------- Co-authored-by: silverwind <[email protected]>
These blocks aren't used anywhere else when doing a grep search.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )