go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.75k stars 5.47k forks source link

Unable to "adopt" orphaned packages like I'm able to adopt orphaned Repositories. #32287

Open CakePost opened 1 week ago

CakePost commented 1 week ago

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.

image image

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

lunny commented 5 days ago

This should be a proposal rather than a bug. And I don't know whether it's possible to recover packages from disk.

CakePost commented 5 days ago

Thanks @lunny I wanted to make this a type/question as I wasn't sure if something like this was even implemented.