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

Docker :latest tag referred to 1.16.0-rc1, now it refers to 1.15.11 (downgrade) #8427

New Issue
Closed
opened 2025-11-02 08:05:34 -06:00 by GiteaMirror · 12 comments
GiteaMirror commented 2025-11-02 08:05:34 -06:00
Owner
Copy Link

Originally created by @DennisGaida on GitHub (Jan 30, 2022).

Gitea Version

1.16.0-rc1

Git Version

No response

Operating System

No response

How are you running Gitea?

docker via https://hub.docker.com/r/gitea/gitea

Database

MySQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

I ran the default gitea image (image: gitea/gitea which means latest) from docker hub, that referred as of 11 days ago to version 1.16.0-rc1. My database version was 209.

The docker version was upated today and :latest now refers to version 1.15.11 which means it is a downgrade from my current version. The log message told me to downgrade:

Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity.
        If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;`

Which I did, but then no login was possible anymore:

2022/01/30 12:54:05 ...ers/web/user/auth.go:209:SignInPost() [I] Failed authentication attempt for <username> from <ip>:0: user does not exist [uid: 2, name: <username>, keyid: 0]
2022/01/30 12:54:05 Completed POST /user/login 200 OK in 52.316221ms

I resolved this issue now by hardcoding the image tag to gitea/gitea:1.16.0-rc1, but I would wish in the future that the latest tag only refers to major versions, not to release candidates.

Screenshots

No response

Originally created by @DennisGaida on GitHub (Jan 30, 2022). ### Gitea Version 1.16.0-rc1 ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? docker via https://hub.docker.com/r/gitea/gitea ### Database MySQL ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Description I ran the default gitea image (`image: gitea/gitea` which means latest) from docker hub, that referred as of 11 days ago to version **1.16.0-rc1**. My database `version` was 209. The docker version was upated today and `:latest` now refers to version 1.15.11 which means it is a downgrade from my current version. The log message told me to downgrade: ``` Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity. If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;` ``` Which I did, but then no login was possible anymore: ``` 2022/01/30 12:54:05 ...ers/web/user/auth.go:209:SignInPost() [I] Failed authentication attempt for <username> from <ip>:0: user does not exist [uid: 2, name: <username>, keyid: 0] 2022/01/30 12:54:05 Completed POST /user/login 200 OK in 52.316221ms ``` I resolved this issue now by hardcoding the image tag to `gitea/gitea:1.16.0-rc1`, but I would wish in the future that the `latest` tag only refers to major versions, not to release candidates. ### Screenshots _No response_
GiteaMirror added the type/bugtopic/build labels 2025-11-02 08:05:34 -06:00
GiteaMirror commented 2025-11-02 08:05:35 -06:00
Author
Owner
Copy Link

@trueAl commented on GitHub (Jan 30, 2022):

Is there any way to recover from that sitch besides "upgrading" to an RC?

@trueAl commented on GitHub (Jan 30, 2022): Is there any way to recover from that sitch besides "upgrading" to an RC?
GiteaMirror commented 2025-11-02 08:05:35 -06:00
Author
Owner
Copy Link

@Rollbacke commented on GitHub (Jan 30, 2022):

Same problem here.
Probably an error, but it's annoying...
In cause, like Dennis, the db version:

gitea       | 2022/01/30 13:25:16 ...dules/setting/log.go:286:newLogService() [I] Gitea v1.15.11 built with GNU Make 4.3, go1.16.13 : bindata, timetzdata, sqlite, sqlite_unlock_notify
gitea       | 2022/01/30 13:25:16 ...dules/setting/log.go:333:newLogService() [I] Gitea Log Mode: Console(Console:)
gitea       | 2022/01/30 13:25:16 ...dules/setting/log.go:249:generateNamedLogger() [I] Router Log: Console(console:)
gitea       | 2022/01/30 13:25:16 ...les/setting/cache.go:78:newCacheService() [I] Cache Service Enabled
gitea       | 2022/01/30 13:25:16 ...les/setting/cache.go:93:newCacheService() [I] Last Commit Cache Service Enabled
gitea       | 2022/01/30 13:25:16 ...s/setting/session.go:77:newSessionService() [I] Session Service Enabled
gitea       | 2022/01/30 13:25:16 ...s/storage/storage.go:171:initAttachments() [I] Initialising Attachment storage with type:
gitea       | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/attachments
gitea       | 2022/01/30 13:25:16 ...s/storage/storage.go:165:initAvatars() [I] Initialising Avatar storage with type:
gitea       | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/avatars
gitea       | 2022/01/30 13:25:16 ...s/storage/storage.go:183:initRepoAvatars() [I] Initialising Repository Avatar storage with type:
gitea       | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-avatars
gitea       | 2022/01/30 13:25:16 ...s/storage/storage.go:177:initLFS() [I] Initialising LFS storage with type:
gitea       | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/git/lfs
gitea       | 2022/01/30 13:25:16 ...s/storage/storage.go:189:initRepoArchives() [I] Initialising Repository Archive storage with type:
gitea       | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-archive
gitea       | 2022/01/30 13:25:16 routers/init.go:95:GlobalInit() [I] SQLite3 Supported
gitea       | 2022/01/30 13:25:16 routers/common/db.go:20:InitDBEngine() [I] Beginning ORM engine initialization.
gitea       | 2022/01/30 13:25:16 routers/common/db.go:27:InitDBEngine() [I] ORM engine initialization attempt #1/10...
gitea       | 2022/01/30 13:25:16 ...om/urfave/cli/app.go:524:HandleAction() [I] PING DATABASE postgres
gitea       | Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity.
gitea       | If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;`
gitea       | 2022/01/30 13:25:16 ...ations/migrations.go:414:Migrate() [F] Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity.
gitea       |   If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;`
@Rollbacke commented on GitHub (Jan 30, 2022): Same problem here. Probably an error, but it's annoying... In cause, like Dennis, the db version: ``` gitea | 2022/01/30 13:25:16 ...dules/setting/log.go:286:newLogService() [I] Gitea v1.15.11 built with GNU Make 4.3, go1.16.13 : bindata, timetzdata, sqlite, sqlite_unlock_notify gitea | 2022/01/30 13:25:16 ...dules/setting/log.go:333:newLogService() [I] Gitea Log Mode: Console(Console:) gitea | 2022/01/30 13:25:16 ...dules/setting/log.go:249:generateNamedLogger() [I] Router Log: Console(console:) gitea | 2022/01/30 13:25:16 ...les/setting/cache.go:78:newCacheService() [I] Cache Service Enabled gitea | 2022/01/30 13:25:16 ...les/setting/cache.go:93:newCacheService() [I] Last Commit Cache Service Enabled gitea | 2022/01/30 13:25:16 ...s/setting/session.go:77:newSessionService() [I] Session Service Enabled gitea | 2022/01/30 13:25:16 ...s/storage/storage.go:171:initAttachments() [I] Initialising Attachment storage with type: gitea | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/attachments gitea | 2022/01/30 13:25:16 ...s/storage/storage.go:165:initAvatars() [I] Initialising Avatar storage with type: gitea | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/avatars gitea | 2022/01/30 13:25:16 ...s/storage/storage.go:183:initRepoAvatars() [I] Initialising Repository Avatar storage with type: gitea | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-avatars gitea | 2022/01/30 13:25:16 ...s/storage/storage.go:177:initLFS() [I] Initialising LFS storage with type: gitea | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/git/lfs gitea | 2022/01/30 13:25:16 ...s/storage/storage.go:189:initRepoArchives() [I] Initialising Repository Archive storage with type: gitea | 2022/01/30 13:25:16 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-archive gitea | 2022/01/30 13:25:16 routers/init.go:95:GlobalInit() [I] SQLite3 Supported gitea | 2022/01/30 13:25:16 routers/common/db.go:20:InitDBEngine() [I] Beginning ORM engine initialization. gitea | 2022/01/30 13:25:16 routers/common/db.go:27:InitDBEngine() [I] ORM engine initialization attempt #1/10... gitea | 2022/01/30 13:25:16 ...om/urfave/cli/app.go:524:HandleAction() [I] PING DATABASE postgres gitea | Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity. gitea | If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;` gitea | 2022/01/30 13:25:16 ...ations/migrations.go:414:Migrate() [F] Downgrading database version from '209' to '189' is not supported and may result in loss of data integrity. gitea | If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;` ```
GiteaMirror commented 2025-11-02 08:05:36 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 30, 2022):

UPDATED: 1.16.0 has pushed to :latest, you can safely pull.

We accident pushed 1.16-rc1 to :latest but it should not be there. So I think there are two workrounds currently.

  1. If you want to still follow :latest, please go to database and change the version table value to 189 and restart.
  2. if you don’t want to change database manually, please change the docker tag to 1.16-rc1, and you can change back when 1.16.0 is released.

I recommand to use the second, there is some risk for the first workround.

I’m very sorry for that problem confusing you.

@lunny commented on GitHub (Jan 30, 2022): UPDATED: 1.16.0 has pushed to `:latest`, you can safely pull. We accident pushed 1.16-rc1 to `:latest` but it should not be there. So I think there are two workrounds currently. 1. ~If you want to still follow `:latest`, please go to database and change the version table value to `189` and restart.~ 2. if you don’t want to change database manually, please change the docker tag to `1.16-rc1`, and you can change back when 1.16.0 is released. **I recommand to use the second**, there is some risk for the first workround. I’m very sorry for that problem confusing you.
GiteaMirror commented 2025-11-02 08:05:36 -06:00
Author
Owner
Copy Link

@kjuulh commented on GitHub (Jan 30, 2022):

Can confirm, I had the same problem with postgres. I ended pinning 1.16.0-rc1 (Now I just need to remember to roll over to 1.16 once that is out).

Btw, will the ORM, be fine if you set the version to 189? Won't it actually corrupt the state of the database. I.E. changes may be there, but the ORM, doesn't know it has already applied the changes.

@kjuulh commented on GitHub (Jan 30, 2022): Can confirm, I had the same problem with postgres. I ended pinning 1.16.0-rc1 (Now I just need to remember to roll over to 1.16 once that is out). Btw, will the ORM, be fine if you set the version to 189? Won't it actually corrupt the state of the database. I.E. changes may be there, but the ORM, doesn't know it has already applied the changes.
GiteaMirror commented 2025-11-02 08:05:36 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 30, 2022):

It should be fine for my expirence when developing but I think you still need to backup before you do downgrade.

@lunny commented on GitHub (Jan 30, 2022): It should be fine for my expirence when developing but I think you still need to backup before you do downgrade.
GiteaMirror commented 2025-11-02 08:05:37 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Jan 30, 2022):

please do not downgrade ... this is due to our pipeline config handling latest tag on release branch too :/

the plan was to tag rc2 afterwards ... but pipeline fail somehow ...

@6543 commented on GitHub (Jan 30, 2022): please do not downgrade ... this is due to our pipeline config handling `latest` tag on release branch too :/ the plan was to tag rc2 afterwards ... but pipeline fail somehow ...
GiteaMirror commented 2025-11-02 08:05:37 -06:00
Author
Owner
Copy Link

@DennisGaida commented on GitHub (Jan 30, 2022):

1. If you want to still follow `:latest`, please go to database and change the version table value to `189` and restart.

2. if you don’t want to change database manually, please change the docker tag to `1.16-rc1`, and you can change back when 1.16.0 is released.

I did what you suggested in method 1, but had the problem that I couldn't login anymore - not even with a fresh user (first login works, every subsequent login doesn't work. I guess some database schema changes, but just to let you know: method 1 doesn't work.

Method 2 works just fine and I'm eagerly awaiting the release of 1.16 then :-)

@DennisGaida commented on GitHub (Jan 30, 2022): > 1. If you want to still follow `:latest`, please go to database and change the version table value to `189` and restart. > > 2. if you don’t want to change database manually, please change the docker tag to `1.16-rc1`, and you can change back when 1.16.0 is released. I did what you suggested in method *1*, but had the problem that I couldn't login anymore - not even with a fresh user (first login works, every subsequent login doesn't work. I guess some database schema changes, but just to let you know: method 1 doesn't work. Method 2 works just fine and I'm eagerly awaiting the release of 1.16 then :-)
GiteaMirror commented 2025-11-02 08:05:37 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 30, 2022):

1. If you want to still follow `:latest`, please go to database and change the version table value to `189` and restart.

2. if you don’t want to change database manually, please change the docker tag to `1.16-rc1`, and you can change back when 1.16.0 is released.

I did what you suggested in method 1, but had the problem that I couldn't login anymore - not even with a fresh user (first login works, every subsequent login doesn't work. I guess some database schema changes, but just to let you know: method 1 doesn't work.

Method 2 works just fine and I'm eagerly awaiting the release of 1.16 then :-)

Ah, that's a bad idea. We are discussing to release 1.16rc2 or 1.16.0 ASAP.

@lunny commented on GitHub (Jan 30, 2022): > > ``` > > 1. If you want to still follow `:latest`, please go to database and change the version table value to `189` and restart. > > > > 2. if you don’t want to change database manually, please change the docker tag to `1.16-rc1`, and you can change back when 1.16.0 is released. > > ``` > > I did what you suggested in method _1_, but had the problem that I couldn't login anymore - not even with a fresh user (first login works, every subsequent login doesn't work. I guess some database schema changes, but just to let you know: method 1 doesn't work. > > Method 2 works just fine and I'm eagerly awaiting the release of 1.16 then :-) Ah, that's a bad idea. We are discussing to release 1.16rc2 or 1.16.0 ASAP.
GiteaMirror commented 2025-11-02 08:05:37 -06:00
Author
Owner
Copy Link

@Rollbacke commented on GitHub (Jan 30, 2022):

If you did a rollback to version 1.15 (even if it was not wanted), should we expect bugs?

@Rollbacke commented on GitHub (Jan 30, 2022): If you did a rollback to version 1.15 (even if it was not wanted), should we expect bugs?
GiteaMirror commented 2025-11-02 08:05:38 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 30, 2022):

1.16.0 is tagged.

@lunny commented on GitHub (Jan 30, 2022): 1.16.0 is tagged.
GiteaMirror commented 2025-11-02 08:05:38 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Jan 30, 2022):

If you did a rollback to version 1.15 (even if it was not wanted), should we expect bugs?

it should just not start until you change a value manually in db - so at that point you should know what you do or have a backup

@6543 commented on GitHub (Jan 30, 2022): > If you did a rollback to version 1.15 (even if it was not wanted), should we expect bugs? it should just not start until you change a value manually in db - so at that point you should know what you do or have a backup
GiteaMirror commented 2025-11-02 08:05:38 -06:00
Author
Owner
Copy Link

@DennisGaida commented on GitHub (Jan 30, 2022):

1.16.0 is tagged.

Wow that was quick! Also published on docker hub as of 9 minutes ago. I pulled and recreated with latest and everything works. Running on 1.16.0 - thank you!

@DennisGaida commented on GitHub (Jan 30, 2022): > 1.16.0 is tagged. Wow that was quick! Also published on docker hub as of 9 minutes ago. I pulled and recreated with latest and everything works. Running on 1.16.0 - thank you!
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 topic/build type/bug
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#8427
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?