github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

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

New Issue
Closed
opened 2025-11-02 06:38:57 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2025-11-02 06:38:57 -06:00
Owner
Copy Link

Originally created by @myitcv on GitHub (Aug 18, 2020).

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 https://github.com/go-gitea/gitea/pull/5290 (a change which was then reverted in https://github.com/go-gitea/gitea/pull/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

Originally created by @myitcv on GitHub (Aug 18, 2020). 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 https://github.com/go-gitea/gitea/pull/5290 (a change which was then reverted in https://github.com/go-gitea/gitea/pull/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 - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] 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
GiteaMirror commented 2025-11-02 06:38:58 -06:00
Author
Owner
Copy Link

@myitcv commented on GitHub (Aug 20, 2020):

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
@myitcv commented on GitHub (Aug 20, 2020): 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 ```
GiteaMirror commented 2025-11-02 06:38:58 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Aug 20, 2020):

Gitea automatically runs migrate when it is started.

See:

c6943cca52/routers/init.go (L76)

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.

@zeripath commented on GitHub (Aug 20, 2020): Gitea automatically runs migrate when it is started. See: https://github.com/go-gitea/gitea/blob/c6943cca52823a679dbff615001541a8bce18c52/routers/init.go#L76 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.
GiteaMirror commented 2025-11-02 06:38:58 -06:00
Author
Owner
Copy Link

@myitcv commented on GitHub (Aug 21, 2020):

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.

@myitcv commented on GitHub (Aug 21, 2020): > 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.
GiteaMirror commented 2025-11-02 06:38:59 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Aug 21, 2020):

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.

@zeripath commented on GitHub (Aug 21, 2020): 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.
GiteaMirror commented 2025-11-02 06:38:59 -06:00
Author
Owner
Copy Link

@myitcv commented on GitHub (Aug 21, 2020):

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.

@myitcv commented on GitHub (Aug 21, 2020): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#5870
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?