support custom file name in gitea dump command
#6474
Conversation
Codecov Report
@@ Coverage Diff @@
## master #6474 +/- ##
======================================
Coverage 39.4% 39.4%
======================================
Files 393 393
Lines 53271 53271
======================================
Hits 20994 20994
Misses 29290 29290
Partials 2987 2987Continue to review full report at Codecov.
|
GiteaBot
added
the
lgtm/need 2
cmd/dump.go
Outdated
| @@ -85,7 +90,7 @@ func runDump(ctx *cli.Context) error { | |||
|
|
|||
| dbDump := path.Join(tmpWorkDir, "gitea-db.sql") | |||
|
|
|||
| fileName := fmt.Sprintf("gitea-dump-%d.zip", time.Now().Unix()) | |||
| fileName := fmt.Sprintf(ctx.String("file"), time.Now().Unix()) | |||
There was a problem hiding this comment.
Also if the value of --file is provided by the user and doesn't have a %d format directive, wouldn't that ruin the value of fileName. If I remember correctly, when a string doesn't have a format directive, the resulting output is something like %!(EXTRA int64=1257894000). So in this case, fileName will end up being userSuppliedFileName%!(EXTRA int64=1257894000) .
There was a problem hiding this comment.
you, sir, are completely right. updated the logic.
|
In my opinion, the default should remain the same with the timestamp, and the override should just override without giving the If a user wants to override the filename, they should provide the exact name they want. If they need a timestamp, they can figure out how to generate it via shell (or whatever terminal they use per their OS). |
|
that‘s how it works with this patch.
|
GiteaBot
added
lgtm/need 1
GiteaBot
added
lgtm/done
cmd/dump.go
Outdated
| fmtString := ctx.String("file") | ||
|
|
||
| if strings.Count(fmtString, "%d") > 0 { | ||
| fmtString = fmt.Sprintf(fmtString, time.Now().Unix()) |
There was a problem hiding this comment.
In reference to my other comment, personally I think this is unnecessary.
If a user wants to override the file name, they should be able to provide the exact name they want, without relying on the code transforming a %d. This code would only transform a single %d as well, and if they had any other formatting symbols before/after, they would also end up with a bad filename.
I will not block this PR, however I don't personally approve of this "magic".
(To clarify, I do like this feature. Overriding the filename would be great. I just don't particularly care for this part.)
There was a problem hiding this comment.
Sorry for the "dupe" comment notification, I forget that comments in the file section don't show up in conversation unless it's marked as a review.
There was a problem hiding this comment.
i see your point and generally agree. but if you don't submit a custom file name with the --file argument, it'll use the default and the default contains %d. so, this check is necessary.
we could change the default to not include %d but that may break existing setups?
There was a problem hiding this comment.
Or change the default value to
Value: fmt.Sprintf("gitea-dump-%d.zip", time.Now().Unix())
There was a problem hiding this comment.
some pseudo code could be:
filename := fmt.Sprintf("gitea-dump-%d.zip", time.Now().Unix())
if ctx.String("file") {
filename = ctx.String("file")
}
and don't do fmt.Sprintf on what is passed in via CLI
There was a problem hiding this comment.
Value: fmt.Sprintf("gitea-dump-%d.zip", time.Now().Unix())
damn. that's brilliant. i'll do that. thank you, sir!
There was a problem hiding this comment.
Either that or what @techknowlogick said. Whichever seems cleaner in the code. 👍
There was a problem hiding this comment.
implemented @jolheiser's approach.
techknowlogick
added
the
type/enhancement
in `gitea dump` command
what
with this patch you can submit a custom nam for the backup file created by
gitea dump.why
without this patch, when writing a backup script which stores my gitea dump off-site, i have to do some weird gymnastics to get the file
gitea dumpwrites to disk because it generates a random file name with the current unix timestamp. likedump_file=$(ls -t|head -1)while being sure to be in an empty directory.with this patch, i can just choose the file's name myself and move on encrypting and uploading it.
compatibility
this change should not affect anybody as the new parameter is optional and has a default value which does not change the known behavior of the binary.