WIP: feat: better parsing of duration in config #10273
Değerlendirici yok
Etiketler
Etiket Yok
arch
riscv64
backport/v1.19
backport/v1.20
backport/v1.21/forgejo
backport/v10.0/forgejo
backport/v11.0/forgejo
backport/v12.0/forgejo
backport/v13.0/forgejo
backport/v14.0/forgejo
backport/v15.0/forgejo
backport/v7.0/forgejo
backport/v8.0/forgejo
backport/v9.0/forgejo
breaking
bug
bug
confirmed
bug
duplicate
bug
needs-more-info
bug
new-report
bug
reported-upstream
code/actions
code/api
code/auth
code/auth/faidp
code/auth/farp
code/email
code/federation
code/git
code/migrations
code/packages
code/wiki
database
MySQL
database
PostgreSQL
database
SQLite
dependency-upgrade
dependency
Chi
dependency
Chroma
dependency
F3
dependency
ForgeFed
dependency
garage
dependency
Gitea
dependency
Golang
Discussion
duplicate
enhancement/feature
forgejo/accessibility
forgejo/branding
forgejo/ci
forgejo/commit-graph
forgejo/documentation
forgejo/furnace cleanup
forgejo/i18n
forgejo/interop
forgejo/moderation
forgejo/privacy
forgejo/release
forgejo/scaling
forgejo/security
forgejo/ui
Gain
High
Gain
Nice to have
Gain
Undefined
Gain
Very High
good first issue
i18n/backport-stable
impact
large
impact
medium
impact
small
impact
unknown
Incompatible license
issue
closed
issue
do-not-exist-yet
issue
open
manual test
Manually tested during feature freeze
OS
FreeBSD
OS
Linux
OS
macOS
OS
Windows
problem
QA
regression
release blocker
Release Cycle
Feature Freeze
release-blocker
v7.0
release-blocker
v7.0.1
release-blocker
v7.0.2
release-blocker
v7.0.3
release-blocker
v7.0.4
release-blocker
v8.0.0
release-blocker/v9.0.0
run-all-playwright-tests
run-end-to-end-tests
stage
2-research
stage
3-design
stage
4-implementation
test
manual
test
needed
test
needs-help
test
not-needed
test
present
untested
User research - time-tracker
valuable code
worth a release-note
User research - Accessibility
User research - Blocked
User research - Community
User research - Config (instance)
User research - Errors
User research - Filters
User research - Future backlog
User research - Git workflow
User research - Labels
User research - Moderation
User research - Needs input
User research - Notifications/Dashboard
User research - Rendering
User research - Repo creation
User research - Repo units
User research - Security
User research - Settings (in-app)
Kilometre Taşı Yok
Proje yok
Atanan Kişi Yok
6 katılımcı
Bildirimler
Bitiş Tarihi
Bitiş tarihi atanmadı.
Bağımlılıklar
Bağımlılık yok.
Referans
forgejo/forgejo!10273
Yükleniyor…
Tablo ekle
Bağlantı ekle
Yeni konuda referans
Herhangi bir açıklama sağlanmadı.
"gusted/forgejo-parsing-duration" Dalını Sil
Bir dalı silmek kalıcıdır. Her ne kadar silinen dal tamamen kaldırılana kadar çok kısa bir süre yaşamını sürdürse de, çoğu durumda bu işlem GERİ ALINAMAZ. Devam edilsin mi?
Release notes
Where does that come from?
The following is a preview of the release notes for this pull request, as they will appear in the upcoming release. They are derived from the content of the `release-notes/10273.md` file, if it exists, or the title of the pull request. They were also added at the bottom of the description of this pull request for easier reference.This message and the release notes originate from a call to the release-notes-assistant.
Release notes
@ -0,0 +1,184 @@// Copyright 2010 The Go Authors. All rights reserved.// Copyright 2025 The Forgejo Authors. All rights reserved.// SPDX-License-Identifier: BSD-3-ClauseLink to upstream so it's easier to follow
https://cs.opensource.google/go/go/+/refs/tags/go1.25.4:src/time/format.go;l=1621
@ -74,1 +74,3 @@LFS.HTTPAuthExpiry = sec.Key("LFS_HTTP_AUTH_EXPIRY").MustDuration(24 * time.Hour)LFS.HTTPAuthExpiry, err = sec.Key("LFS_HTTP_AUTH_EXPIRY").MustDuration(24 * time.Hour)if err != nil {return fmt.Errorf("could not parse duration for [server].LFS_HTTP_AUTH_EXPIRY: %w", err)Is there a semantic difference between
could not parse durationandFailed to parse duration? They seem like an inconsistency to me.Not really.
@ -0,0 +73,4 @@"h": uint64(time.Hour),// Added, take a common definition."d": uint64(time.Hour * 24),LOGIN_REMEMBER_DAYScould make use of this, but this can be scoped out....also
USERNAME_COOLDOWN_PERIOD,[log] MAX_DAYS,[actions].ARTIFACT_RETENTION_DAYS,[actions].LOG_RETENTION_DAYSHave you considered attempting to upstream these changes, or you're expecting that Google will reply with "parsing
d,wand returning error for invalid values is not in scope of this package"? Or making it an external package and importing it?Thank you very much. I think this is great to allow admins to calculate longer values (mostly in days) without the need to convert it into and from hours.
What happens if a unit is not understood. Does it fail (my preferred behaviour) or silently fall back to the default value (current behaviour)?
@ -0,0 +75,4 @@// Added, take a common definition."d": uint64(time.Hour * 24),"w": uint64(time.Hour * 24 * 7),"mo": uint64(time.Hour * 24 * 31),Is this commonly used to configure software? I haven't encountered it yet. If it is used, is 31 the common unit?
I am used to configuring software in days or years, and if using days, mostly multiples of 30 (e.g. 30, 60, 90, 120, 180 days etc).
I'm also not sure about the
moandydurations. If we just add the interpretations for days and weeks, users could use4was a rough equivalent for a month and either365dor52wfor the year. Thinking further about it, the only useful addition (at least from my point of view) is the unit for days. Using days as the unit ensures no ambiguity when dealing with months.For example, if someone expects to cleanup old stuff every month,
1mocould end up in a lot of confusion after February 28th.30don the other hand as a configuration value leaves much less room for interpretation.I think years could make sense for configuring multi-year retention. E.g. clean up action logs and artifacts after 2 years, recorded activities after 3 years. Calculating multiple years in days is also very inconvenient.
I am not sure if any Forgejo admin ever configured it like this, though. The most important addition is probably days.
I can drop month and week.
The PR is WIP because the documentation still has to be written that will clearly state that these are just shorthand for other durations and will not take into account any logic regarding dates.
@0ko wrote in #10273 (yorum):
https://github.com/golang/go/issues/17767#issuecomment-258167205
Well that was 9 years ago but another issue was closed just recently with same reasoning, so that clarifies it. What about an external package? Or developers who would like to reuse this could just import
codeberg.org/forgejo/forgejo/durationif they want?@0ko wrote in #10273 (yorum):
Yes maybe, but given the small amount of code there's a proverb that applies here https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s. IIRC @fogti had a similar question regarding making the
modulesdirectory a importable package. I'm afraid this would be a larger discussion.e429d04d9add2a5820fbdd2a5820fbad591407bcad591407bcc8a22db9c6@Gusted can this pull request be considered ready for review and
WIP:removed?@limiting-factor wrote in #10273 (yorum):
The PR is ready, but I hadn't got around to write the necessary documentation PR for it.
Komut satırı talimatlarını görüntüleyin.
Elle(manuel) birleştirme yardımcısı
Birleştirme işlemini kendiniz elle(manuel olarak) tamamlarken bu birleştirmenin değişiklik(commit) mesajını kullanın.
Çekme
Proje deponuzdan yeni bir dalı çekin ve değişiklikleri test edin.