Description
Description
A few days ago I encountered an issue with the postgres database I was using for our Gitea instance. I documented the events that caused the corruption of our database on serverfault in the hopes of being able to recover it, though that's looking unlikely.
I'm now facing the process of recovering our instance to the best of my ability. Using the "adopt repository" feature a lot of the stress is mitigated as I can just have users remake their accounts (of which there are only 30) and then relink their repositories. However, a few users have been using packages and I'd like to also be able to restore those as well.
Wiping the corrupted database (after a backup of course) and starting fresh, an execution of the gitea doctor shows this:
/$ gitea doctor check --all
[1] Garbage collect LFS
- [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s)
OK
[2] Check paths and basic configuration
- [I] Configuration File Path: "/data/gitea/conf/app.ini"
- [I] Repository Root Path: "/data/git/repositories"
- [I] Data Root Path: "/data/gitea"
- [I] Custom File Root Path: "/data/gitea"
- [I] Work directory: "/data/gitea"
- [I] Log Root Path: "/data/gitea/log"
OK
[3] Check if there are orphaned archives in storage
- [I] Found 0 (0 B) repo archive(s)
OK
[4] Check if there are orphaned attachments in storage
- [I] Found 0 (0 B) attachment(s)
OK
[5] Check if there are orphaned avatars in storage
- [W] Found 15/16 (1.8 MiB/1.8 MiB) orphaned avatar(s)
- [I] Found 0 (0 B) repo avatar(s)
OK
[6] Check if there are orphaned lfs files in storage
- [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s)
OK
[7] Check if there are orphaned package blobs in storage
- [W] Found 81/81 (295 MiB/295 MiB) orphaned package blob(s)
OK
[8] Check if there are orphaned storage files
- [I] Found 0 (0 B) attachment(s)
- [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s)
- [W] Found 15/16 (1.8 MiB/1.8 MiB) orphaned avatar(s)
- [I] Found 0 (0 B) repo avatar(s)
- [I] Found 0 (0 B) repo archive(s)
- [W] Found 81/81 (295 MiB/295 MiB) orphaned package blob(s)
OK
[9] Check Database Version
- [I] Expected database version: 280
OK
[10] Check consistency of database
- [W] Found 2 Orphaned OAuth2Application without existing User
OK
[11] Check if user with wrong type exist
OK
[12] Check if OpenSSH authorized_keys file is up-to-date
OK
[13] Deleted all content related to orphaned repos
OK
[14] Check if SCRIPT_TYPE is available
- [I] ScriptType bash is on the current PATH at /bin/bash
OK
[15] Check if hook files are up-to-date and executable
OK
[16] Recalculate Stars number for all user
- [I] No check available for User Stars numbers (skipped)
OK
[17] Check old archives
- [I] 0 old archives in repository need to be deleted
OK
[18] Check that all git repositories have receive.advertisePushOptions set to true
- [I] Checked 1 repositories, 0 need updates.
OK
[19] Check for incorrectly dumped repo_units (See #16961)
- [I] Found no broken repo_units
OK
[20] Check for incorrect can_create_org_repo for org owner teams
- [I] Found no team with incorrect can_create_org_repo
OK
[21] Recalculate merge bases
- [I] All 0 PRs in 1 repos have a correct mergebase
OK
[22] Synchronize repo HEADs
- [I] All 1 repos have their HEADs in the correct state
OK
[23] Check git-daemon-export-ok files
- [I] Checked 1 repositories, 0 need updates.
OK
[24] Check commit-graphs
- [I] Checked 1 repositories, 1 without commit-graphs.
OK
[25] Check if users has an valid email address
- [I] All users have a valid e-mail.
OK
[26] Check if users have a valid username
- [I] All users have a valid username.
OK
All done (checks: 26).
Of course running gitea doctor check --all --fix just deletes anything that's orphaned. What I'd like to do is be able to re-associate all of the orphaned packages back with the accounts that made them.
I do not know if this is something that can be done through the interface somewhere I'm missing, or if it can be done through the command line. Before I start having people re-onboarded onto the server, I'd like to know what I can do to get their packages back onto their accounts.
Gitea Version
1.21.6
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
While the repository section in the site administration panel provides a really easy way to re-associate repos with their users (once recreating their accounts), the package code assets do not seem to have this option.
Git Version
2.30.2
Operating System
Debian GNU/Linux 11 (bullseye)
How are you running Gitea?
I am running gitea in a docker container using the following docker compose config.
version: "3.9"
services:
gitea:
image: gitea/gitea:latest
restart: always
hostname: ###.###.###.###
environment:
- USER=git
- USER_UID=1000
- USER_GID=998
- GITEA__database__DB_TYPE=postgres
- GITEA__database___HOST=giteadb:5432
- GITEA__database__NAME=gitea
- GITEA__database__USER=gitea
- GITEA__database__PASSWD=###################
networks:
- gitea
ports:
- 3000:3000
- 22:22
volumes:
- /mnt/###################/gitea/data:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
shm_size: 256m
depends_on:
- giteadb
giteadb:
image: postgres:14
restart: always
environment:
- POSTGRES_USER=gitea
- POSTGRES_PASSWORD=###################
- POSTGRES_DB=gitea
networks:
- gitea
volumes:
- /srv/###################/gitea/db:/var/lib/postgresql/data
runner:
image: gitea/act_runner:latest
restart: always
depends_on:
- gitea
volumes:
- /mnt/###################/gitea/data/act_runner:/data
- /var/run/docker.sock:/var/run/docker.sock
environment:
- GITEA_INSTANCE_URL=https://git.###################.com
# When using Docker Secrets, it's also possible to use
# GITEA_RUNNER_REGISTRATION_TOKEN_FILE to pass the location.
# The env var takes precedence.
# Needed only for the first start.
- GITEA_RUNNER_REGISTRATION_TOKEN=###################
networks:
gitea:
external: false
Database
PostgreSQL