Description
- Gitea version (or commit ref): v1.14.2
- Git version: 2.30.2
- Operating system: Docker container built from this repository for linux/arm/v7 architecture with Docker buildx. No customizations done on the sources from which the container was built. The resulting container runs on a Raspberry Pi 4B+.
- Database (use
[x]):- PostgreSQL
- MySQL
- MSSQL
- SQLite
- Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
note: successful migration here: https://try.gitea.io/MPeter/mx-puppet-bridge
as far as I know, there are no differences in how I cloned the repository.
- Log gist:
Not sure what should I exactly provide, but here are the logs from when I try to open the migrated repository from the repo list of y repos: https://gist.github.com/MPeti1/45637568af8485a6a82dadfed4c98740
The log starts 40 minuteslater than when I set up the debug level logging according to the link provided in the issue template, and then restarted the gitea container. This is because a problem with s6-supervise and time64 on 32 bit systems, that has theoretically been fixed both in the undrlying alpine version, and on the host system's docker and libseccomp2 vesion, but still occurs, and the logs have filled the log buffer that Docker keeps.
The log was obtained by running docker-compose logs -t > logs.txt.
Description
If I migrate a (public) repository from Github by providing an access token and selecting the Wiki to be mirrored too, migration takes a long time (minutes) before failing. The repository, when the migration failed, can't be deleted in the usual way, because on opening it's page it retries the migration, where it will fail again.
Migrating the same repository without giving the access token results in a very fast (<= 5 seconds) and successful migration. By successfull, I mean that the repository looks as any other in it's normal state (screenshot below).
It's yet unknown to me if providing an access token or selecting the Wiki to be mirrored results in the migration to fail, I'll try to check that.
A somewhat (possibly) rare configuration option I made and could be relevant is that I have set up Gitea as an offline instance, which is only to be used in my local network.
Screenshots
The "migration in progress" menu on opening the broken repo:
A successful migration of the same repository, if done without access token and Wiki:
The error on the migration page, when Gitea recognized that this migration has failed:
Haven't seen that page in a few retries now, but I'll upload a screenshot if I see it again.
