Running gitea migrate appears to race with starting server using docker-compose

[myitcv]

Firstly, thanks for this awesome project.

I've searched the issue tracker and can't seem to find anything that deals with the specific issue, although I note something related is discussed in #5290 (a change which was then reverted in #5730).

I've also done some preliminary investigation via Discord with @techknowlogick (many thanks):

https://discordapp.com/channels/322538954119184384/345384901144477698/745266163038289940

• Gitea version (or commit ref): 1.13.0+dev-15-gc572ee2b6
• Git version: 2.24.3
• Operating system: Ubuntu 20.04.1 LTS
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist: n/a

Description

Run the following steps to create a bare-bones gitea setup using Docker (config is basically taken from https://docs.gitea.io/en-us/install-with-docker/):

cat <<EOD > docker-compose.yml
version: "2"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:latest
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
      - ./app.ini:/data/gitea/conf/app.ini:ro
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"
EOD
cat <<EOD > app.ini
APP_NAME = Gitea: Git with a cup of tea
RUN_MODE = dev

[repository]
ROOT = /data/git/repositories

[repository.local]
LOCAL_COPY_PATH = /data/gitea/tmp/local-repo

[repository.upload]
TEMP_PATH = /data/gitea/uploads

[server]
APP_DATA_PATH    = /data/gitea
DOMAIN           = localhost
SSH_DOMAIN       = localhost
HTTP_PORT        = 3000
ROOT_URL         =
DISABLE_SSH      = false
SSH_PORT         = 22
SSH_LISTEN_PORT  = 22
LFS_START_SERVER = false
LFS_CONTENT_PATH = /data/git/lfs

[database]
PATH    = /data/gitea/gitea.db
DB_TYPE = sqlite3
HOST    = localhost:3306
NAME    = gitea
USER    = root
PASSWD  =

[indexer]
ISSUE_INDEXER_PATH = /data/gitea/indexers/issues.bleve

[session]
PROVIDER_CONFIG = /data/gitea/sessions

[picture]
AVATAR_UPLOAD_PATH            = /data/gitea/avatars
REPOSITORY_AVATAR_UPLOAD_PATH = /data/gitea/repo-avatars

[attachment]
PATH = /data/gitea/attachments

[log]
ROOT_PATH = /data/gitea/log

[security]
INSTALL_LOCK   = false
SECRET_KEY     =
INTERNAL_TOKEN = eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1OTc3ODc2NjF9.lEoOYUuqcEP9H25L75NbjkJYForjxaFJOMb34CAwwJI

[service]
DISABLE_REGISTRATION = false
REQUIRE_SIGNIN_VIEW  = false

[oauth2]
JWT_SECRET = c9u1QaYp5ABFXx15388Wt8GsXz5RZqzvD7el9cA1vyE

EOD

Now start gitea:

docker-compose up -d

Now try and add a new user:

docker-compose exec server gitea --config /data/gitea/conf/app.ini admin create-user --admin --username root --password asdffdsa --email blah@blah.com

This fails with:

...
2020/08/18 22:58:20 main.go:112:main() [F] Failed to run app with [gitea --config /data/gitea/conf/app.ini admin create-user --admin --username root --password asdffdsa --email blah@blah.com]: CreateUser: no such table: user

Indeed this command only appears to work if I run the following first:

docker-compose exec server gitea migrate

However, it appears that running the migrate admin task immediately after starting gitea (via docker-compose up -d) creates some sort of race condition where the migrate can fail.

So this is as much a question as a bug report: what should I be doing here?

@techknowlogick suggested that the migrate step was unnecessary, but it appears to be required. Yet running migrate soon after starting gitea appears to race with something, causing the migrate to fail.

Thanks in advance.

Screenshots

n/a

[myitcv]

Here is one of the error messages that I get when, apparently, the starting of the gitea server races with a run of the gitea migrate admin command:

2020/08/20 17:37:10 cmd/migrate.go:38:runMigrate() [F] Failed to initialize ORM engine: sync database struct error: index IDX_user_is_active already exists

[zeripath]

Gitea automatically runs migrate when it is started.

See:

gitea/routers/init.go

Line 76 in c6943cc

if err = models.NewEngine(ctx, migrations.Migrate); err == nil {

It should therefore be unnecessary to explicitly run migrate. (Except where you want to explicitly run it to test things.)

You shouldn't run migrate whilst Gitea is running.

[myitcv]

Gitea automatically runs migrate when it is started.

Thanks. So it sounds like there is a bug here because as I mention in the original description, if I run docker-compose up and then try to add an admin user via:

docker-compose exec server gitea --config /data/gitea/conf/app.ini admin create-user --admin --username root --password asdffdsa --email blah@blah.com

(with gitea running) then I get the error:

...
2020/08/21 05:37:15 main.go:112:main() [F] Failed to run app with [gitea --config /data/gitea/conf/app.ini admin create-user --admin --username root --password asdffdsa --email blah@blah.com]: CreateUser: no such table: user

which seems to suggest that migrations have not been run.

[zeripath]

The lack of a User table suggests that the database has not been created let alone migrated.

If you look at your app.ini:

INSTALL_LOCK   = false

That pushes Gitea into Install mode which would not init the db because Gitea is expecting to be told where the DB is to be created.

You would need to set

INSTALL_LOCK=true

and provide the INTERNAL_TOKEN, JWT_SECRET, LFS_JWT_SECRET, and SECRET_KEY.

gitea generate secret ...

could be used to generate those however.

[myitcv]

Thank you very much, @zeripath. INSTALL_LOCK appears to be what I was missing here. Appreciate you taking the time to reply. I'll close this issue as there is indeed no bug here.