gitea dump #2971

New Issue

GiteaMirror · 2025-11-02T04:55:42-06:00

GiteaMirror commented

2025-11-02 04:55:42 -06:00

Originally created by @85pando on GitHub (Feb 25, 2019).

Gitea version (or commit ref): 1.5.1 (went through the changelog, found nothing to indicate this has been changed)
Git version: irrelevant
Operating system: Debian GNU Linux 9
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant (dump is not testable on try.gitea.io)
Log gist: -

Description

tl;dr

Current behaviour: When using gitea --dump -c /etc/gitea/app.ini the output is written to stderr
Expected behaviour: When using gitea --dump -c /etc/gitea/app.ini the output should be written to stdout. stderr should only be used to inform about problems or errors.

long text with context:

On our server we have a backup script responsible for backing up a multitude of things. The result of this process is mailed to the server admins. A log from the stderr of the backup process is attached to the mail.
As gitea dump writes to stderr this section of the mail is now non-empty even when nothing went wrong.

====================
backup.debug
====================
2019/02/25 05:07:59 Creating tmp work dir: /tmp/gitea-dump-446568747
2019/02/25 05:07:59 Dumping local repositories.../var/lib/gitea/gitea-repositories
2019/02/25 05:08:06 Dumping database...
2019/02/25 05:08:10 Packing dump files...
2019/02/25 05:08:13 Removing tmp work dir: /tmp/gitea-dump-446568747
2019/02/25 05:08:13 Finish dumping in file gitea-dump-1551067690.zip
Connected to backup.
====================
backup.log
====================
[… long list of backup stati]
Will now create backup of Gitea repositories and SQL: gitea-dump.2019.02.25.zip
...done, 66.14 M
[… long list of backup stati]

Screenshots

Originally created by @85pando on GitHub (Feb 25, 2019). - Gitea version (or commit ref): 1.5.1 (went through the changelog, found nothing to indicate this has been changed) - Git version: irrelevant - Operating system: Debian GNU Linux 9 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant (dump is not testable on try.gitea.io) - Log gist: - ## Description ### tl;dr - **Current behaviour:** When using ```gitea --dump -c /etc/gitea/app.ini``` the output is written to ```stderr``` - **Expected behaviour:** When using ```gitea --dump -c /etc/gitea/app.ini``` the output should be written to ```stdout```. ```stderr``` should only be used to inform about problems or errors. ### long text with context: On our server we have a backup script responsible for backing up a multitude of things. The result of this process is mailed to the server admins. A log from the ```stderr``` of the backup process is attached to the mail. As ```gitea dump``` writes to ```stderr``` this section of the mail is now non-empty even when nothing went wrong. ``` ==================== backup.debug ==================== 2019/02/25 05:07:59 Creating tmp work dir: /tmp/gitea-dump-446568747 2019/02/25 05:07:59 Dumping local repositories.../var/lib/gitea/gitea-repositories 2019/02/25 05:08:06 Dumping database... 2019/02/25 05:08:10 Packing dump files... 2019/02/25 05:08:13 Removing tmp work dir: /tmp/gitea-dump-446568747 2019/02/25 05:08:13 Finish dumping in file gitea-dump-1551067690.zip Connected to backup. ==================== backup.log ==================== [… long list of backup stati] Will now create backup of Gitea repositories and SQL: gitea-dump.2019.02.25.zip ...done, 66.14 M [… long list of backup stati] ``` ## Screenshots

GiteaMirror added the issue/confirmed type/enhancement labels 2025-11-02 04:55:42 -06:00

GiteaMirror closed this issue

2025-11-02 04:55:42 -06:00

GiteaMirror commented

2025-11-02 04:55:43 -06:00

@techknowlogick commented on GitHub (Feb 25, 2019):

Logging and also the dB library have been updated and so please upgrade to the latest stable version and try again. In the mean time you can run a dB backup manually using MySQL dump and zipping the data directory to do a backup before upgrading

@techknowlogick commented on GitHub (Feb 25, 2019): Logging and also the dB library have been updated and so please upgrade to the latest stable version and try again. In the mean time you can run a dB backup manually using MySQL dump and zipping the data directory to do a backup before upgrading

GiteaMirror commented

2025-11-02 04:55:43 -06:00

@85pando commented on GitHub (Feb 25, 2019):

Just setup a fresh install on a virtual machine with reduced backup script, same result.

gitea version: 1.7.2
database:
- SQLite

== err ==
2019/02/25 20:46:59 Creating tmp work dir: /tmp/gitea-dump-695934806
2019/02/25 20:46:59 Dumping local repositories.../home/git/gitea-repositories
2019/02/25 20:46:59 Dumping database...
[…]

In the mean time you can run a dB backup manually using MySQL dump

Just to clarify: the dump works fine, restore is also possible, it's just the wrong logging target from my point of view.

@85pando commented on GitHub (Feb 25, 2019): Just setup a fresh install on a virtual machine with reduced backup script, same result. - gitea version: 1.7.2 - database: - [x] SQLite ``` == err == 2019/02/25 20:46:59 Creating tmp work dir: /tmp/gitea-dump-695934806 2019/02/25 20:46:59 Dumping local repositories.../home/git/gitea-repositories 2019/02/25 20:46:59 Dumping database... […] ``` - - - - > In the mean time you can run a dB backup manually using MySQL dump Just to clarify: the dump works fine, restore is also possible, it's just the wrong logging target from my point of view.

GiteaMirror commented

2025-11-02 04:55:43 -06:00

@stale[bot] commented on GitHub (Apr 27, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Apr 27, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:55:43 -06:00

@85pando commented on GitHub (May 4, 2019):

Thanks kind stale bot.

@85pando commented on GitHub (May 4, 2019): Thanks kind stale bot.

GiteaMirror referenced this issue

2025-11-02 12:16:22 -06:00

[PR #2971] [MERGED] Fix bench deps since #2916 #16686

Sign in to join this conversation.