Errors after upgrade from latest gogs to gitea 1.1.2

Hello every one

I got stuck with the following error after the upgrade from the latest gogs to gitea 1.1.2:

remote: 2017/07/12 19:54:04 [FATAL] [...g/setting/setting.go:543 NewContext()] Expect user 'gogs' but current user is: gitea

This error occours at git push.

Here the holle output:

cyrill@vhost:~/StuffAndThings> git push
Counting objects: 7, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (7/7), 468 bytes | 0 bytes/s, done.
Total 7 (delta 0), reused 0 (delta 0)
remote: 2017/07/12 19:56:45 [FATAL] [...g/setting/setting.go:543 NewContext()] Expect user 'gogs' but current user is: gitea
To gitea@git.ch:BrosFTW/StuffAndThings.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'gitea@git.ch:BrosFTW/StuffAndThings.git'


cyrill@vhost:~/StuffAndThings> git config --list
user.name=BigGold1310
user.email=cyrill.naef@example.com
user.email=cyrill@example.ch
push.default=simple
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=gitea@git.ch:BrosFTW/StuffAndThings.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
cyrill@vhost:~/StuffAndThings>

My config option in the app.ini looks like the following now:

APP_NAME = GIT
RUN_USER = gitea
RUN_MODE = prod

I’m 100% sure that the server starts gitea with the gitea user. Same issue if I start the server manualy by hand with that user.

Steps to reproduce

  1. Install latest gogs version and run it under user gogs
  2. Create some repositories
  3. Migrate from gogs to gitea and start it with a new user called gitea
  4. Try to push any data to the repository

Can anyone help me?

Try running Resync pre-receive, update and post-receive hooks of all repositories. in Admin Panel Dashboard

Also keep in mind that upgrade from latest gogs is not supported directly. You need to change database migration version to v14 before upgrading to gitea in database table version.
You can do it by running sql query update version set version=14;

I am quite sure the problem is the RUN_USER variable in the config file is set to gogs, when it seems like it should be gitea.

Code: modules/setting/setting.go L796-803

I have redone the upgrade. (Reseted every thing.)

I copyed the database from gogs to gitea. Changed the version with update version set version=14;

I removed all repositories and recopyed them. After I changed the owner from gogs to gitea.

After all that I started gitea with ./gitea web . Now I tryed to push again and I got the same error as before:

cyrill@vhost:~/StuffAndThings> git push
Counting objects: 2, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 316 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: 2017/07/13 06:42:33 [FATAL] [...g/setting/setting.go:543 NewContext()] Expect user 'gogs' but current user is: gitea
To gitea@git.ch:BrosFTW/StuffAndThings.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'gitea@git.ch:BrosFTW/StuffAndThings.git'

Did you do this from Admin Settings Dashboard?

yes. I have done this through the admin panel.

Did you try replacing RUN_USER=gogs with RUN_USER=gitea in the config file.

yes. see my initial post.

APP_NAME = GIT
RUN_USER = gitea
RUN_MODE = prod

Could you git pull successfully?

But the error clearly states that the config got a value of Gogs instead of gitea

Can you post here pre-receive file content form servers BrosFTW/StuffAndThings.git/hooks/ directory?

It seems there are the same gogs SSH public keys still in .ssh/authorized_keys so that a gogs command has been invoked.

I have done a quick and dirty work around.

I have setup a new fresh gitea installation and merged all repositories to the new installation.

Now every thing works as expected.

If anyone is interested in debugging these issue we can progress on the failed instance itself.