-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new [lfs_client].BATCH_SIZE and [server].LFS_MAX_BATCH_SIZE config settings. #32307
Conversation
fyi I ignored two failures under test-backend from Also, if there is a separate docs site I should be updating with the new gitea config, I would appreciate a pointer to where that lives. |
You can send doc pull request here https://gitea.com/gitea/docs |
related doc pr: https://gitea.com/gitea/docs/pulls/83 |
And maybe we should split lfs server configurations and lfs client configurations. |
Fair enough @lunny , although it looks like the built-in lfs server doesn't have any constraint on batch size today: https://github.com/go-gitea/gitea/blob/main/services/lfs/server.go#L186 If you're in agreement, the way I'd go about this is:
If that sounds good, I'll update this branch with all that. |
I prefer to put the new configuration under a new section |
That's a bit confusing to me. All the other configs for lfs are under
And what I was proposing:
We could make the argument for a config refactoring though, where we have |
Put all lfs configuration items under |
I thought that's what you were getting at, okay so what if we put new configs for lfs under a combined section, like:
That would keep this pr simple without adding more config debt. In a separate PR I could extend the new lfs config class to handle old/new config sections and add warnings for their potential future deprecations. |
129b5d2
to
1fef084
Compare
1fef084
to
f695949
Compare
f695949
to
d314dff
Compare
Okay, I went with this (very similar to what we agreed upon above, but removing the duplicate LFS_ prefix):
I added a test for these defaults, and opened up #32332 to track the refactor/migration of the lfs configs under [server] to [lfs.server]. EDIT: apologies for the all the force-pushes, found a spelling error in a comment and forgot to actually implement the server-side response when MAX_BATCH_SIZE was breached. This PR is ready for review again. |
d314dff
to
b6afdc2
Compare
b6afdc2
to
d01a505
Compare
services/lfs/server.go
Outdated
@@ -179,6 +179,12 @@ func BatchHandler(ctx *context.Context) { | |||
return | |||
} | |||
|
|||
batchSize := len(br.Objects) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LFSClient.BatchSize hasn't been used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's used the line below actually batchSize > setting.LFSServer.MaxBatchSize
, but you're right that it's only used once. I was considering whether to put a debug line to print the batch size the client requested. Would you prefer:
- leave as-is
- add such a debug line
- remove this var and just get the length in-line for that same check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove the lfs.client and the configuration items if no place use that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay, I think I probably don't want a log line, so I've moved this inline. We can add it back if we want logging later.
b47a030
to
9de1d58
Compare
The config system becomes more messy:
Would they cause problems for maintainers and site admin? |
@wxiaoguang would you prefer:
Or something else? I'll let you and @lunny hash it out, although I think we're all in agreement that we don't want more lfs-specific configs under |
I have no clear idea at the moment and I don't mean against it. Just a question. |
Maybe we |
NO. |
But |
I've tried to summarize two of the suggested organizations of this config in #32332 just so we can visualize what they look like. |
No. Because the See below Details how the
Renaming config items involves a lot of backwards compatibility work ...... I am not sure if there would be some people spending time on it and make it right. And keep in mind that it can't use The only clear approach in my mind is (that's just my opinion, maybe it doesn't need to hurry to do any change before there is a consensus) |
…g settings. This contains two backwards-compatible changes: * in the lfs http_client, the number of lfs oids requested per batch is loaded from lfs_client#BATCH_SIZE and defaulted to the previous value of 20 * in the lfs server/service, the max number of lfs oids allowed in a batch api request is loaded from server#LFS_MAX_BATCH_SIZE and defaults to 'nil' which equates to the previous behavior of 'infinite' This fixes go-gitea#32306 Signed-off-by: Royce Remer <royceremer@gmail.com>
379c752
to
02f9dd4
Compare
Updated this branch and https://gitea.com/gitea/docs/pulls/83 with @wxiaoguang's preference of:
Should we then close/never #32332 ? Seems like we're committing to not refactoring the lfs configs and keeping it all under |
* origin/main: (21 commits) Fix toAbsoluteLocaleDate and add more tests (go-gitea#32387) Respect UI.ExploreDefaultSort setting again (go-gitea#32357) Fix absolute-date (go-gitea#32375) Fix undefined errors on Activity page (go-gitea#32378) Add new [lfs_client].BATCH_SIZE and [server].LFS_MAX_BATCH_SIZE config settings. (go-gitea#32307) remove unused call to $.HeadRepo in view_title template (go-gitea#32317) Fix clean tmp dir (go-gitea#32360) Optimize branch protection rule loading (go-gitea#32280) Suggestions for issues (go-gitea#32327) Migrate vue components to setup (go-gitea#32329) Fix db engine (go-gitea#32351) Refactor the DB migration system slightly (go-gitea#32344) Fix broken image when editing comment with non-image attachments (go-gitea#32319) Fix disable 2fa bug (go-gitea#32320) Upgrade rollup to 4.24.0 (go-gitea#32312) Upgrade vue to 3.5.12 (go-gitea#32311) Make admins adhere to branch protection rules (go-gitea#32248) Prevent from submitting issue/comment on uploading (go-gitea#32263) Add warn log when deleting inactive users (go-gitea#32318) Add `DISABLE_ORGANIZATIONS_PAGE` and `DISABLE_CODE_PAGE` settings for explore pages and fix an issue related to user search (go-gitea#32288) ...
* giteaofficial/main: Fix suggestions for issues (go-gitea#32380) refactor: remove redundant err declarations (go-gitea#32381) Fix the missing menu in organization project view page (go-gitea#32313) Fix toAbsoluteLocaleDate and add more tests (go-gitea#32387) Respect UI.ExploreDefaultSort setting again (go-gitea#32357) Fix absolute-date (go-gitea#32375) Fix undefined errors on Activity page (go-gitea#32378) Add new [lfs_client].BATCH_SIZE and [server].LFS_MAX_BATCH_SIZE config settings. (go-gitea#32307) remove unused call to $.HeadRepo in view_title template (go-gitea#32317) Fix clean tmp dir (go-gitea#32360) Optimize branch protection rule loading (go-gitea#32280) Suggestions for issues (go-gitea#32327) Migrate vue components to setup (go-gitea#32329)
This contains two backwards-compatible changes:
* in the lfs http_client, the number of lfs oids requested per batch is loaded from lfs_client#BATCH_SIZE and defaulted to the previous value of 20
* in the lfs server/service, the max number of lfs oids allowed in a batch api request is loaded from server#LFS_MAX_BATCH_SIZE and defaults to 'nil' which equates to the previous behavior of 'infinite'
This fixes #32306