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

pre-receive hook error after updating #12848

New Issue
Closed
opened 2025-11-02 10:22:47 -06:00 by GiteaMirror · 9 comments
GiteaMirror commented 2025-11-02 10:22:47 -06:00
Owner
Copy Link

Originally created by @grafwolg on GitHub (Apr 15, 2024).

Description

After updating from 1.21.3 to 1.21.10 we get client errors when trying to push to every repository available.
All repos do have only the standard /hooks/pre-receive.d/gitea hook available.
Hooks have been deleted manually an rebuild via gitea admin or web admin but also then we get errors like this:

ompressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 365 bytes | 121.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote:
remote: Gitea: Internal Server Error Decoding Failed
To https://git.intern.ksb.com/grafwol/programming.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.intern.ksb.com/areaname/reponame.git'

Error log was set to debug but does not report any error

Workaround was to completly delete the hook files -- but that might only be temporary

Gitea Version

1.21.10 (latest)

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

docker bundled one

Operating System

docker linux

How are you running Gitea?

Gitea is used in docker verson as gitea/gitea or gitea/gitea:1.21

Database

SQLite

Originally created by @grafwolg on GitHub (Apr 15, 2024). ### Description After updating from 1.21.3 to 1.21.10 we get client errors when trying to push to every repository available. All repos do have only the standard /hooks/pre-receive.d/gitea hook available. Hooks have been deleted manually an rebuild via gitea admin or web admin but also then we get errors like this: ompressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 365 bytes | 121.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0) remote: remote: Gitea: Internal Server Error Decoding Failed To https://git.intern.ksb.com/grafwol/programming.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'https://git.intern.ksb.com/areaname/reponame.git' Error log was set to debug but does not report any error Workaround was to completly delete the hook files -- but that might only be temporary ### Gitea Version 1.21.10 (latest) ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version docker bundled one ### Operating System docker linux ### How are you running Gitea? Gitea is used in docker verson as gitea/gitea or gitea/gitea:1.21 ### Database SQLite
GiteaMirror added the issue/not-a-bug label 2025-11-02 10:22:47 -06:00
GiteaMirror commented 2025-11-02 10:22:48 -06:00
Author
Owner
Copy Link

@yp05327 commented on GitHub (Apr 16, 2024):

I think there should be some logs like this in backend:
unable to decode error response xxx: xxx

It seems that it will be stored in SSH log.
from: #23687
image

@yp05327 commented on GitHub (Apr 16, 2024): ~~I think there should be some logs like this in backend:~~ `unable to decode error response xxx: xxx` It seems that it will be stored in SSH log. from: #23687 ![image](https://github.com/go-gitea/gitea/assets/18380374/6fa47721-af63-4985-98c0-ade24c6bd9c6)
GiteaMirror commented 2025-11-02 10:22:48 -06:00
Author
Owner
Copy Link

@grafwolg commented on GitHub (Apr 16, 2024):

Regarding the comment of ssh.log: I read the tech backgrounds but was not able to identify where this ssh log file could be found, maybe you should guide me a little bit there, thanks in advance!

On server side in gitea.log (debug level) there is a entry like this:

2024/04/16 05:57:54 ...eb/routing/logger.go:102:func1() [I] router: completed GET /CAxPLM/weg.git/info/refs?service=git-receive-pack for 10.250.5.80:0, 401 Unauthorized in 0.3ms @ web/githttp.go:16(web.requireSignIn)
2024/04/16 05:57:54 ...dules/git/command.go:290:Run() [D] git.Command.RunDir(/data/git/repositories/caxplm/weg.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c fi lter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc --advertise-refs .
2024/04/16 05:57:54 ...eb/routing/logger.go:102:func1() [I] router: completed GET /CAxPLM/weg.git/info/refs?service=git-receive-pack for 10.250.5.80:0, 200 OK in 8.2ms @ repo/gith ttp.go:532(repo.GetInfoRefs)
2024/04/16 05:57:54 ...dules/git/command.go:290:Run() [D] git.Command.RunDir(/data/git/repositories/caxplm/weg.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c fi lter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc /data/git/repositories/caxplm/weg.git
2024/04/16 05:57:55 ...eb/routing/logger.go:102:func1() [I] router: completed POST /CAxPLM/weg.git/git-receive-pack for 10.250.5.80:0, 200 OK in 153.4ms @ repo/githttp.go:500(repo .ServiceReceivePack)

Notably is that in this particular case the git client is windows with default windows credential manager sucessfully able to clone the repo or - in other cases native linux with default git installation. So the Unauthorized message is not fully transparent to me.

On client side you get a message like:

OST git-receive-pack (516 bytes)
remote:
remote: Gitea: Internal Server Error Decoding Failed
remote: Gitea: HookPreReceive(last) failed: unable to decode error response "POST http://gitea:3000/api/internal/hook/pre-receive/CAxPLM/weg": readObjectStart: expect { or n, but found <, error found in #1 byte of ...|<!DOCTYPE h|..., bigger context ...|<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transi|...
Pus

Note that the docker container internally has a hostname of gitea listening to port 3000, externally this is rewritten to https://git.intern.blabla.com, but this worked since ages.

@grafwolg commented on GitHub (Apr 16, 2024): Regarding the comment of ssh.log: I read the tech backgrounds but was not able to identify where this ssh log file could be found, maybe you should guide me a little bit there, thanks in advance! On server side in gitea.log (debug level) there is a entry like this: ********** 2024/04/16 05:57:54 ...eb/routing/logger.go:102:func1() [I] router: completed GET /CAxPLM/weg.git/info/refs?service=git-receive-pack for 10.250.5.80:0, 401 Unauthorized in 0.3ms @ web/githttp.go:16(web.requireSignIn) 2024/04/16 05:57:54 ...dules/git/command.go:290:Run() [D] git.Command.RunDir(/data/git/repositories/caxplm/weg.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c fi lter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc --advertise-refs . 2024/04/16 05:57:54 ...eb/routing/logger.go:102:func1() [I] router: completed GET /CAxPLM/weg.git/info/refs?service=git-receive-pack for 10.250.5.80:0, 200 OK in 8.2ms @ repo/gith ttp.go:532(repo.GetInfoRefs) 2024/04/16 05:57:54 ...dules/git/command.go:290:Run() [D] git.Command.RunDir(/data/git/repositories/caxplm/weg.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c fi lter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc /data/git/repositories/caxplm/weg.git 2024/04/16 05:57:55 ...eb/routing/logger.go:102:func1() [I] router: completed POST /CAxPLM/weg.git/git-receive-pack for 10.250.5.80:0, 200 OK in 153.4ms @ repo/githttp.go:500(repo .ServiceReceivePack) ************* Notably is that in this particular case the git client is windows with default windows credential manager sucessfully able to clone the repo or - in other cases native linux with default git installation. So the *Unauthorized* message is not fully transparent to me. On client side you get a message like: OST git-receive-pack (516 bytes) remote: remote: Gitea: Internal Server Error Decoding Failed remote: Gitea: HookPreReceive(last) failed: unable to decode error response "POST http://gitea:3000/api/internal/hook/pre-receive/CAxPLM/weg": readObjectStart: expect { or n, but found <, error found in #1 byte of ...|<!DOCTYPE h|..., bigger context ...|<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transi|... Pus Note that the docker container internally has a hostname of gitea listening to port 3000, externally this is rewritten to https://git.intern.blabla.com, but this worked since ages.
GiteaMirror commented 2025-11-02 10:22:49 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Apr 16, 2024):

Can you run ./gitea doctor to check whether the location of your gitea binary has been changed?

@lunny commented on GitHub (Apr 16, 2024): Can you run `./gitea doctor` to check whether the location of your gitea binary has been changed?
GiteaMirror commented 2025-11-02 10:22:49 -06:00
Author
Owner
Copy Link

@grafwolg commented on GitHub (Apr 16, 2024):

Thank you for the fast answer!
Hi, as we are running in docker env (provided the image of docker hub) I did run within the container.
As expected nothing weird happened then, except the first message (see comment below)

Run as git user within docker container

vngitp:~$ gitea doctor check
2024/04/16 08:28:45 .../setting/security.go:168:loadSecurityFrom() [W] Enabling Query API Auth tokens is not recommended. DISABLE_QUERY_AUTH_TOKEN will default to true in gitea 1.23 and will be removed in gitea 1.24.

[1] Check paths and basic configuration
 - [I] Configuration File Path:    "/data/gitea/conf/app.ini"
 - [I] Repository Root Path:       "/data/git/repositories"
 - [I] Data Root Path:             "/data/gitea"
 - [I] Custom File Root Path:      "/data/gitea"
 - [I] Work directory:             "/data/gitea"
 - [I] Log Root Path:              "/data/gitea/log"
OK

[2] Check Database Version
 - [I] Expected database version: 280
OK

[3] Check if user with wrong type exist
OK

[4] Check if OpenSSH authorized_keys file is up-to-date
OK

[5] Synchronize repo HEADs
 - [I] All 314 repos have their HEADs in the correct state
OK

All done (checks: 5).

I checked my app.ini config and do not have a non-defaul entry of DISABLE_QUERY_AUTH_TOKEN as mentioned in the message of the doctor

vngitp:~$ cat /data/gitea/conf/app.ini | grep DISABLE_QUERY_AUTH_TOKEN
vngitp:~$

But maybe this is just a message without real informational content

@grafwolg commented on GitHub (Apr 16, 2024): Thank you for the fast answer! Hi, as we are running in docker env (provided the image of docker hub) I did run within the container. As expected nothing weird happened then, except the first message (see comment below) Run as git user within docker container ```bash vngitp:~$ gitea doctor check 2024/04/16 08:28:45 .../setting/security.go:168:loadSecurityFrom() [W] Enabling Query API Auth tokens is not recommended. DISABLE_QUERY_AUTH_TOKEN will default to true in gitea 1.23 and will be removed in gitea 1.24. [1] Check paths and basic configuration - [I] Configuration File Path: "/data/gitea/conf/app.ini" - [I] Repository Root Path: "/data/git/repositories" - [I] Data Root Path: "/data/gitea" - [I] Custom File Root Path: "/data/gitea" - [I] Work directory: "/data/gitea" - [I] Log Root Path: "/data/gitea/log" OK [2] Check Database Version - [I] Expected database version: 280 OK [3] Check if user with wrong type exist OK [4] Check if OpenSSH authorized_keys file is up-to-date OK [5] Synchronize repo HEADs - [I] All 314 repos have their HEADs in the correct state OK All done (checks: 5). ``` I checked my app.ini config and do not have a non-defaul entry of DISABLE_QUERY_AUTH_TOKEN as mentioned in the message of the doctor ```bash vngitp:~$ cat /data/gitea/conf/app.ini | grep DISABLE_QUERY_AUTH_TOKEN vngitp:~$ ``` But maybe this is just a message without real informational content
GiteaMirror commented 2025-11-02 10:22:50 -06:00
Author
Owner
Copy Link

@grafwolg commented on GitHub (Apr 16, 2024):

if it helps I can try to execute any hook manually from within container.

@grafwolg commented on GitHub (Apr 16, 2024): if it helps I can try to execute any hook manually from within container.
GiteaMirror commented 2025-11-02 10:22:50 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Apr 16, 2024):

Please change your configuration [server]LOCAL_ROOT_URL=http(s)://127.0.0.1:<port> in app.ini and try agin.

@lunny commented on GitHub (Apr 16, 2024): Please change your configuration `[server]LOCAL_ROOT_URL=http(s)://127.0.0.1:<port>` in app.ini and try agin.
GiteaMirror commented 2025-11-02 10:22:50 -06:00
Author
Owner
Copy Link

@grafwolg commented on GitHub (Apr 16, 2024):

Changed from

 [server]LOCAL_ROOT_URL=http://gitea:3000
 to 
[server]LOCAL_ROOT_URL=http://localhost:3000

Works perfect for pushing, thanx.

One small side effect: the gitea runner for actions do need a hostname known to them (which was the reason to set it to gitea as hostname. Now with setting it to "localhost" the runners are not working any more.
Should I open this as a new bug ?

@grafwolg commented on GitHub (Apr 16, 2024): Changed from ```bash [server]LOCAL_ROOT_URL=http://gitea:3000 to [server]LOCAL_ROOT_URL=http://localhost:3000 ``` Works perfect for pushing, thanx. One small side effect: the gitea runner for actions do need a hostname known to them (which was the reason to set it to gitea as hostname. Now with setting it to "localhost" the runners are not working any more. Should I open this as a new bug ?
GiteaMirror commented 2025-11-02 10:22:50 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Apr 16, 2024):

They are two options.
[server]ROOT_URL=http://gitea:3000 this is the external visiting URL out of container and also runner will visit this URL.
[server]LOCAL_ROOT_URL=http://localhost:3000 this is for the internal usage URL which should not be visited by out of this container/machine.

@lunny commented on GitHub (Apr 16, 2024): They are two options. `[server]ROOT_URL=http://gitea:3000` this is the external visiting URL out of container and also runner will visit this URL. `[server]LOCAL_ROOT_URL=http://localhost:3000` this is for the internal usage URL which should not be visited by out of this container/machine.
GiteaMirror commented 2025-11-02 10:22:51 -06:00
Author
Owner
Copy Link

@grafwolg commented on GitHub (Apr 16, 2024):

Thank you again for this explanation. Now it works perfectly
Kind regards

@grafwolg commented on GitHub (Apr 16, 2024): Thank you again for this explanation. Now it works perfectly Kind regards
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 issue/not-a-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#12848
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?