[BUG] In 1.15.0, git push activites does not work, webhook on push not work #16428
Comments
|
I'm likely being completely dense but I can't for the life of me understand what it is that is not happening when it should and what it is that you're trying to do. The videos are not that helpful by themselves. Please describe what it is you are doing. |
duchenpaul
changed the title
Sorry for the inconvinience, I expanded more details about the issue, if you have any questions, please let me know |
|
I cannot reproduce this on my local macOS Gitea instance. |
|
I suspect that you need to resynchronize the hooks. Also ensure that your repositories are not being mounted as noexec |
|
Your browser is obscuring the most important part of the logs too. When you make the push there should be a call to:
if that's not there then it's clear that your hooks aren't either being run or are being sent to the wrong place. |
|
Take a step back, on https://try.gitea.io, I just tried to do so in https://try.gitea.io, there is no such update on my dashboard. You can see the last commit is if you go to my profile, the last update is |
|
In order to reproduce, please:
|
|
I can confirm; I have the same behavior in 1.15.0+dev-582-g3dcb3e907 Creating a new repository via UI, copy/paste initial commands and pushing README to master, and UI never shows code, but the introductory message. I veriefied that the data are actually pushed and the bare repository has the "first commit" pushed, but web-UI still displays hint on how to add origin or make first commit. |
|
@multicast yeah, if you use webhook, it won't trigger |
|
@duchenpaul no, create repo, git init/touch/add...push, and the repo on the web looks like no push happened. but repositories/user/name.git does contain the commit. there is no special webhook added yet to newly created repo yet. |
|
I can reproduce this issue with a newly created docker instance on 1.15.0 (latest).
If you revert to 1.14.4 everything works as expected. |
|
I was now on the same journey and confirm :latest tag is buggy and :1.14.4 works. The database version has been bumped since 1.14.4 several times, what issues I can expect when looking at models/migrations/v178 ... 188.go? |
duchenpaul
changed the title
I just did this and could not reproduce. |
|
When you push do you get logs: If you do not see: Then the communication between the git repository hooks and the running gitea process is not working. In recent times this has most commonly been occurring because your repositories are mounted on a noexec partition which will not work for gitea. |
|
@zeripath I am running it on my test machine with ubuntu 20.04.2 LTS. But as a matter of fact, i can't see the hook execution as you have stated in your post above. |
|
When you do the git push gitea will normally tell you about what refs it's sending up - do you see that information? If not the hooks aren't running and this is a noexec issue - not sure what will have changed but something either permissions or noexec is stopping them from running. If you do then this is a configuration issue and the hooks are communicating with a different gitea... You can add |
|
Output of git push: Working directory of gitea: Output of Permissions of hooks of the test/test repository ( The config i use is the default config, only customized by the gitea installer. And i can't stress enough that the old tag is working just fine. |
So the hooks aren't running ...
... then it's not being mounted noexec by the docker container - but that does not rule out noexec or capabilities/permissions issues.
This wasn't the kind of permission I was thinking of. There was an issue in Arch whereby because our pre-receive scritpt used I was wondering about that kind of permissions problem.
Ah... I wasn't aware that you were running a compose environment - my test was to simply do a This means suspicion should head to the compose configuration. However it would be helpful to make some small edits to the pre-receive hook to attempt to check if the issue is a noexec or a crash instead. The #!/usr/bin/env bash
data=$(cat)
exitcodes=""
hookname=$(basename $0)
GIT_DIR=${GIT_DIR:-$(dirname $0)}
for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
test -x "${hook}" && test -f "${hook}" || continue
echo "${data}" | "${hook}"
exitcodes="${exitcodes} $?"
done
for i in ${exitcodes}; do
[ ${i} -eq 0 ] || exit ${i}
doneif you edit this file to: #!/usr/bin/env bash
echo "Pre-receive: pre cat"
data=$(cat)
echo "Pre-receive: Data ${data}"
exitcodes=""
hookname=$(basename $0)
GIT_DIR=${GIT_DIR:-$(dirname $0)}
for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
echo "Pre-receive: looking at ${hook}"
test -x "${hook}" && test -f "${hook}" || continue
echo "Pre-receive: running ${hook}"
echo "${data}" | "${hook}"
exitcodes="${exitcodes} $?"
done
for i in ${exitcodes}; do
[ ${i} -eq 0 ] || exit ${i}
doneThen push again and we should be able to see if even the pre-receive hook runs. One thing to double check is that bash is actually installed on your docker compose too. Following on from that you should then take a look at the pre-receive.d/gitea and double check that that looks right and that gitea hook is executable. |
As the docker image is not managed by me i do not decide which software is installed and which is not. If it is not installed but needed then it's clearly a misconfigured image.
Done Output is now as follows: So the scripts are running.
Adding a line to this file which echoes something did not appear while pushing again. |
|
So in your echos we see: But not: Which strangely means that: Is failing and so the gitea hook script is not running. I guess more echos are called for to work out which one of those tests is failing |
|
@Xenolphthalein can you run docker info and return the output? we switched to alpine:3.14 as a base image, and some older versions of docker may not play nicely with syscalls |
|
I've just tried the compose route: ( docker-compose.ymlversion: "3"
networks:
gitea:
external: false
services:
server:
image: gitea/gitea:latest
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:22"app.iniAPP_NAME = Gitea: Git with a cup of tea
RUN_MODE = prod
RUN_USER = git
[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 = http://localhost:3000/
DISABLE_SSH = false
SSH_PORT = 2222
SSH_LISTEN_PORT = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /data/git/lfs
LFS_JWT_SECRET = xxxx
OFFLINE_MODE = false
[database]
PATH = /data/gitea/gitea.db
DB_TYPE = sqlite3
HOST = localhost:3306
NAME = gitea
USER = root
PASSWD =
LOG_SQL = false
SCHEMA =
SSL_MODE = disable
CHARSET = utf8
[indexer]
ISSUE_INDEXER_PATH = /data/gitea/indexers/issues.bleve
[session]
PROVIDER_CONFIG = /data/gitea/sessions
PROVIDER = file
[picture]
AVATAR_UPLOAD_PATH = /data/gitea/avatars
REPOSITORY_AVATAR_UPLOAD_PATH = /data/gitea/repo-avatars
DISABLE_GRAVATAR = false
ENABLE_FEDERATED_AVATAR = true
[attachment]
PATH = /data/gitea/attachments
[log]
MODE = console
LEVEL = info
ROUTER = console
ROOT_PATH = /data/gitea/log
[security]
INSTALL_LOCK = true
SECRET_KEY = xxxx
REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = *
INTERNAL_TOKEN = xxx
PASSWORD_HASH_ALGO = pbkdf2
[service]
DISABLE_REGISTRATION = false
REQUIRE_SIGNIN_VIEW = false
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL = false
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
ENABLE_CAPTCHA = false
DEFAULT_KEEP_EMAIL_PRIVATE = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING = true
NO_REPLY_ADDRESS = noreply.localhost
[mailer]
ENABLED = false
[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true
`docker version`I'm really confused as to what is going on here. |
|
But I can see that try.gitea.io isn't working! For both http and ssh pushing. |
This is `docker version` info from trySooo... this means if we stick with alpine 3.14 then we need to note the minimum version of docker required. Here are minimum requirements: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2 |
|
So... it is the alpine 3.14 PR then and it was a capabilities/permissions issue. I think we probably have to revert the alpine 3.14 PR - and move that to later in 1.16. Then we can deprecate docker 19 this cycle and make the break in 1.16. |
|
@zeripath yeah :( That's probably the best direction. I'll send the PRs |
|
whilst you're at it you could approve the three PRs I just dropped fixing some of my own earlier stupidity! |
I mean, others missed it too, so... but this was an easy thing to miss so I wouldn't beat yourself up over it. |
|
PR sent. thanks to everyone who reported this issue and for providing detailed follow up information so we could trace where this was happening. |
[x]):Sorry, but I dont see any error/abnormals in logs of gitea.
Description
I upgraded my gitea image to the latest version in dockerhub.
And the webhook no longer works, I found that my git push activities are not presenting in my dashboard.
Looks like the new version gitea totally missed my git push activities.
Action
You push a commit to a repo.
Expected
Your commit shows up in the dashboard, like below,
The webhook of this repo will be triggered by this push
Actual
Below is my recordings about that, all I test is to push a commit into the repo, and expect this action to be shown in the dashboad, and demostrate that it works in the older version, and not working in the newest one
Screenshots
Git activities works in v1.14.4
Git activities breaks in v1.15.0
The text was updated successfully, but these errors were encountered: