push commits after upgrade from 1.8.3 to 1.9.3 errors happen

[xuenhua]

• Gitea version (or commit ref): 1.9.3
• Git version: 2.7
• Operating system: ubuntu 16
• 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:

Description

some error happen when push commits after upgrad from 1.8.3 to 1.9.3.

$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 228 bytes | 228.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Gitea: Internal error
remote: retrieve protected branches information failed: invalid character '<' looking for beginning of value
To https://abc.com/abc/test_123.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://abc.com/abc/test_123.git'

Screenshots

[lunny]

Have you changed the binary location on server? If that, you should Resynchronize pre-receive, update and post-receive hooks of all repositories. on admin panel.

[TheOneValen]

I have the same problem. And it is the pre-receove hooks. It still had

#!/usr/bin/env bash
"/home/git/gogs/gogs" hook --config='/home/git/gogs/custom/conf/app.ini' pre-receive

In it for a very long time. I did a clean-up and suddenly had this problem. Now I symlinked gitea to the old gogs location.

• Resynchronize pre-receive, update and post-receive hooks of all repositories. Did not resolve the issue! The hook stayed the same after resynchronisation.
• What does the command do anyway? Is there any possible damage when using a very old gogs binary in this hook?

[xuenhua]

I just upgrade the gitea from 1.8.3 to 1.9.3, without other changes. I did not change the binary location of repositories and other settings.

[lunny]

@xuenhua any logs on your log files.

[xuenhua]

which file

[xuenhua]

I wonder such logs are useful
[Macaron] 2019-09-17 14:41:29: Completed GET /serviceworker.js 200 OK in 3.338673ms
[Macaron] 2019-09-17 14:41:30: Started GET /xuenhua/test_123 for 127.0.0.1
[Macaron] 2019-09-17 14:41:30: Completed GET /xuenhua/test_123 200 OK in 14.394596ms
[Macaron] 2019-09-17 14:41:30: Started GET /manifest.json for 127.0.0.1
[Macaron] 2019-09-17 14:41:30: Completed GET /manifest.json 200 OK in 2.935006ms
[Macaron] 2019-09-17 14:41:32: Started GET /serviceworker.js for 127.0.0.1
[Macaron] 2019-09-17 14:41:32: Completed GET /serviceworker.js 200 OK in 3.330843ms
[Macaron] 2019-09-17 14:41:35: Started GET /xuenhua/test_123/_upload/master/ for 127.0.0.1
[Macaron] 2019-09-17 14:41:35: Completed GET /xuenhua/test_123/_upload/master/ 200 OK in 13.072578ms
[Macaron] 2019-09-17 14:41:35: Started GET /manifest.json for 127.0.0.1
[Macaron] 2019-09-17 14:41:35: Completed GET /manifest.json 200 OK in 3.299891ms
[Macaron] 2019-09-17 14:41:37: Started GET /serviceworker.js for 127.0.0.1
[Macaron] 2019-09-17 14:41:37: Completed GET /serviceworker.js 200 OK in 3.307204ms
[Macaron] 2019-09-17 14:41:41: Started POST /xuenhua/test_123/upload-file for 127.0.0.1
[Macaron] 2019-09-17 14:41:41: Completed POST /xuenhua/test_123/upload-file 200 OK in 55.845246ms
[Macaron] 2019-09-17 14:41:59: Started POST /xuenhua/test_123/_upload/master/ for 127.0.0.1
[Macaron] 2019-09-17 14:41:59: Started GET /api/internal/branch/37/master for 127.0.0.1
[Macaron] 2019-09-17 14:41:59: Completed GET /api/internal/branch/37/master 404 Not Found in 3.065485ms
[Macaron] 2019-09-17 14:41:59: Completed POST /xuenhua/test_123/_upload/master/ 200 OK in 110.812589ms
[Macaron] 2019-09-17 14:41:59: Started GET /manifest.json for 127.0.0.1
[Macaron] 2019-09-17 14:41:59: Completed GET /manifest.json 200 OK in 2.870682ms
[Macaron] 2019-09-17 14:42:01: Started GET /serviceworker.js for 127.0.0.1
[Macaron] 2019-09-17 14:42:01: Completed GET /serviceworker.js 200 OK in 3.266996ms
[Macaron] 2019-09-17 14:42:32: Started POST /xuenhua/test_123/_upload/master/ for 127.0.0.1
[Macaron] 2019-09-17 14:42:32: Completed POST /xuenhua/test_123/_upload/master/ 302 Found in 9.927761ms
[Macaron] 2019-09-17 14:42:32: Started GET /xuenhua/test_123/src/branch/master/ for 127.0.0.1
[Macaron] 2019-09-17 14:42:32: Completed GET /xuenhua/test_123/src/branch/master/ 200 OK in 19.485299ms
[Macaron] 2019-09-17 14:42:32: Started GET /manifest.json for 127.0.0.1
[Macaron] 2019-09-17 14:42:32: Completed GET /manifest.json 200 OK in 2.956812ms
[Macaron] 2019-09-17 14:42:34: Started GET /serviceworker.js for 127.0.0.1
[Macaron] 2019-09-17 14:42:34: Completed GET /serviceworker.js 200 OK in 3.069879ms
[Macaron] 2019-09-17 14:42:35: Started GET /xuenhua/test_123 for 127.0.0.1
[Macaron] 2019-09-17 14:42:35: Completed GET /xuenhua/test_123 200 OK in 15.604941ms
[Macaron] 2019-09-17 14:42:35: Started GET /manifest.json for 127.0.0.1
[Macaron] 2019-09-17 14:42:35: Completed GET /manifest.json 200 OK in 2.966108ms
[Macaron] 2019-09-17 14:42:36: Started GET /xuenhua/test_123 for 127.0.0.1
[Macaron] 2019-09-17 14:42:36: Completed GET /xuenhua/test_123 200 OK in 16.345422ms
[Macaron] 2019-09-17 14:42:36: Started GET /manifest.json for 127.0.0.1
[Macaron] 2019-09-17 14:42:36: Completed GET /manifest.json 200 OK in 3.286769ms
[Macaron] 2019-09-17 14:42:37: Started GET /serviceworker.js for 127.0.0.1
[Macaron] 2019-09-17 14:42:37: Completed GET /serviceworker.js 200 OK in 3.508641ms
[Macaron] 2019-09-17 14:42:38: Started GET /xuenhua/test_123/commits/branch/master for 127.0.0.1
[Macaron] 2019-09-17 14:42:38: Completed GET /xuenhua/test_123/commits/branch/master 200 OK in 25.251356ms
[Macaron] 2019-09-17 14:42:38: Started GET /manifest.json for 127.0.0.1
[Macaron] 2019-09-17 14:42:38: Completed GET /manifest.json 200 OK in 3.174733ms
[Macaron] 2019-09-17 14:42:38: Started GET /serviceworker.js for 127.0.0.1
[Macaron] 2019-09-17 14:42:38: Completed GET /serviceworker.js 200 OK in 2.8168ms
[Macaron] 2019-09-17 14:42:39: Started GET /serviceworker.js for 127.0.0.1

[xuenhua]

@xuenhua any logs on your log files.

I have feedbacked log messages， why the status is still “need feedback”

[guillep2k]

Sorry, @xuenhua , the logs don't seem very useful. Perhaps enabling a TRACE level log in app.ini will give us more information.
But by the look of your first comment, I suspect a regression in how git is called can be the culprit (#7775 is intended to fix that). Can you try upgrading git in your server to a newer version? If the problem is what I think, that should fix it.

[zeripath]

I think this is still a hook problem.

I am not certain why resync hooks command failed though. Is it possible that the hooks are say owned by root?

@xuenhua could you paste a copy of one of the internal hooks of your repositories?

[xuenhua]

Sorry, @xuenhua , the logs don't seem very useful. Perhaps enabling a TRACE level log in app.ini will give us more information.
But by the look of your first comment, I suspect a regression in how git is called can be the culprit (#7775 is intended to fix that). Can you try upgrading git in your server to a newer version? If the problem is what I think, that should fix it.

You can recur this problem just replace the binary file “gitea-1.8.3-linux-amd64” with “gitea-1.9.3-linux-amd64” in Ubuntu OS

[zeripath]

@xuenhua - Sorry I missed your last comment. From what you are saying I think this is the situation:

• You have a gitea 1.8.3 installed as say /home/git/gitea-1.8.3-linux-amd64
• You then delete that file
• And put gitea-1.9.3 in /home/git/gitea-1.9.3-linux-amd64
• Then run gitea from that file.

The reason why your hooks don't work is because they will refer to the old path of the gitea executable unless you update them using the admin task:

Resynchronize pre-receive, update and post-receive hooks of all repositories.

If that doesn't work you need to check the permissions on your gitea-repositories on the server

If you have gogs scripts in the hooks directories you need to remove them. To be more explicit, that is if there is a $GITEA_REPOSITORIES/username/reponame.git/hooks/pre-receive.d/gogs, $GITEA_REPOSITORIES/username/reponame.git/hooks/post-receive.d/gogs or $GITEA_REPOSITORIES/username/reponame.git/hooks/update.d/gogs you need to remove them.

[guillep2k]

@xuenhua in case you've missed it:

[TheOneValen]

The new hooks are put into pre-receive.d/gitea whereas the old hooks were pre-receive.d/pre-receive and still contain references to the gogs binary. Now there are two hooks and the old one throws the error.

[guillep2k]

The new hooks are put into pre-receive.d/gitea whereas the old hooks were pre-receive.d/pre-receive and still contain references to the gogs binary. Now there are two hooks and the old one throws the error.

Maybe you should try and delete those old triggers manually. I'm not sure why you still have triggers from Gogs. My hooks with Gitea 1.10.0:

$ find hooks/ -type f
hooks/applypatch-msg.sample
hooks/commit-msg.sample
hooks/post-update.sample
hooks/pre-applypatch.sample
hooks/pre-commit.sample
hooks/pre-push.sample
hooks/pre-receive.sample
hooks/update.sample
hooks/fsmonitor-watchman.sample
hooks/pre-rebase.sample
hooks/prepare-commit-msg.sample
hooks/pre-receive.d/gitea
hooks/pre-receive
hooks/update.d/gitea
hooks/update
hooks/post-receive.d/gitea
hooks/post-receive

# Without the sample files
$ find hooks/ -type f | fgrep -v sample
hooks/pre-receive.d/gitea
hooks/pre-receive
hooks/update.d/gitea
hooks/update
hooks/post-receive.d/gitea
hooks/post-receive

To remove the old hooks you can go through them and delete them one by one, but there's a faster method you can use if you are certain that you don't have any custom hooks (i.e. generated through the UI or other external means). If you have only "standard" hooks, you can try removing the hooks directory from each repo. Gitea can rebuild the required ones with the procedure detailed in my previous comment. Be aware that this will remove all custom hooks.

Please make a backup of anything you may delete before proceeding.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.