mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2026-07-25 10:57:37 +00:00
0a57672544
Fixes #2325. This introduces a way to download downsized versions of the user and repository avatars: * `/avatars/123abcd` still serves the full-size avatar * `/avatars/123abcd?size=64` serves it at size 64x64 px Those downsized versions are computed on demand when requested for the first time and cached. The caching is done in a storage location configurable in the instance settings, just like the storage locations for the full-sized avatars are. The sizes of the downsized images are restricted to a fixed set of sizes, so that the cache doesn't grow too big. The caching and resizing logic is exposed in a way that could potentially be reused for other types of images (such as user uploads in issue discussions). Luckily, the Go templates already specify in many places which size those avatars should be rendered, even if this information was only used for external avatar providers (such as Gravatar) until now. The range of sizes requested by the HTML templates is rather wide: the table below lists all the sizes I could find, and the corresponding size served by the backend with the logic I implemented. The scaling factor of 2 was already used for requesting resized external avatars, and likely exists to make sure that users with display scaling enabled get a sharper picture. | Size requested in the template | After scaling (x2) | Size of the image served | |---------|---------|---------| | 256 px | 512 px | original (512 px) | | 140 px | 280 px | original (512 px) | | 48 px | 96 px | 128 px | | 40 px | 80 px | 128 px | | 32 px | 64 px | 64 px | | 28 px | 56 px | 64 px | | 24 px | 48 px | 64 px | | 20 px | 40 px | 64 px | Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11242 Reviewed-by: Gusted <gusted@noreply.codeberg.org>
52 lines
1.7 KiB
Go
52 lines
1.7 KiB
Go
// Copyright 2022 The Gitea Authors. All rights reserved.
|
|
// SPDX-License-Identifier: MIT
|
|
|
|
package doctor
|
|
|
|
import (
|
|
"context"
|
|
"errors"
|
|
"time"
|
|
|
|
"forgejo.org/modules/log"
|
|
"forgejo.org/modules/setting"
|
|
"forgejo.org/services/repository"
|
|
)
|
|
|
|
func init() {
|
|
Register(&Check{
|
|
Title: "Garbage collect LFS",
|
|
Name: "gc-lfs",
|
|
IsDefault: false,
|
|
Run: garbageCollectLFSCheck,
|
|
AbortIfFailed: false,
|
|
SkipDatabaseInitialization: false,
|
|
Priority: 1,
|
|
})
|
|
}
|
|
|
|
func garbageCollectLFSCheck(ctx context.Context, logger log.Logger, autofix bool) error {
|
|
if !setting.LFS.StartServer {
|
|
return errors.New("LFS support is disabled")
|
|
}
|
|
|
|
if err := repository.GarbageCollectLFSMetaObjects(ctx, repository.GarbageCollectLFSMetaObjectsOptions{
|
|
LogDetail: logger.Info,
|
|
AutoFix: autofix,
|
|
// Only attempt to garbage collect lfs meta objects older than a week as the order of git lfs upload
|
|
// and git object upload is not necessarily guaranteed. It's possible to imagine a situation whereby
|
|
// an LFS object is uploaded but the git branch is not uploaded immediately, or there are some rapid
|
|
// changes in new branches that might lead to lfs objects becoming temporarily unassociated with git
|
|
// objects.
|
|
//
|
|
// It is likely that a week is potentially excessive but it should definitely be enough that any
|
|
// unassociated LFS object is genuinely unassociated.
|
|
OlderThan: time.Now().Add(-24 * time.Hour * 7),
|
|
// We don't set the UpdatedLessRecentlyThan because we want to do a full GC
|
|
}); err != nil {
|
|
logger.Error("Couldn't garbage collect LFS objects: %v", err)
|
|
return err
|
|
}
|
|
|
|
return CheckStorage(&CheckStorageOptions{LFS: true})(ctx, logger, autofix)
|
|
}
|