-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any events on webhook send twice #9183
Comments
Have you add webhooks on both repository webhook setting and orgnization webhook setting? |
In the beginning, I used only the settings in the repository. Then, for the test, webhook was also added to the global settings, but this did not affect the double sending in any way. Duplicate notifications were from the start. Subsequent experiments with deleting, adding webhook, repositories and other types of events did not change the situation. |
I cannot reproduce this on my local instance. Could you reproduce this on try.gitea.io ? |
I received confirmation that the duplication of webhook depends on the installation configuration. I deployed on the local machine about 10 times and got different results depending on whether I redefined the parameters through ENV. In my product version in kubernetes, where I initially received an error, I also deployed with parameters predefined via ENV. I attach my docker-compose.yaml file, as well as the resulting app.ini. At the installation stage, I only specify ssh_domain and administrator authorization settings. As far as I could understand, if you do not pass EMV when deploying, then gitea does not duplicate webhook. I did not have enough time to figure out more specifically which parameter in the deployment leads to such an error. I hope you can repeat my experiment. After the deployment and installation, I did:
|
I experience the same issue. Every webhook (types "Slack" and "Gitea" in use, all added at repository level) is triggered twice when pushing from Git client (SSH or HTTPS). As far as I can tell, it happens on any repository. I'm running two separate instances. Both same version and about the same configuration, updated regularily since 1.1 or 1.2. Sadly I cannot remember when it started. Faulty instance: app.iniAPP_NAME = git @ mydomain.example.com RUN_USER = git RUN_MODE = prod [database] DB_TYPE = mysql HOST = /var/run/mysqld/mysqld.sock NAME = gitea USER = gitea PASSWD = *** SSL_MODE = disable PATH = data/gitea.db [repository] ROOT = /opt/gitea/repo [server] SSH_DOMAIN = git.mydomain.example.com PROTOCOL = unix HTTP_ADDR = /opt/gitea/gitea.sock HTTP_PORT = 3000 UNIX_SOCKET_PERMISSION = 666 ROOT_URL = https://git.mydomain.example.com/ DISABLE_SSH = false DISABLE_HTTP_GIT = true SSH_PORT = 2222 SSH_LISTEN_PORT = 2222 START_SSH_SERVER = true OFFLINE_MODE = true LANDING_PAGE = explore [mailer] ENABLED = true HOST = mail.example.com:587 FROM = "Git" <git@example.com> USER = git@example.com PASSWD = *** [service] REGISTER_EMAIL_CONFIRM = false ENABLE_NOTIFY_MAIL = true DISABLE_REGISTRATION = true ENABLE_CAPTCHA = false REQUIRE_SIGNIN_VIEW = false [picture] DISABLE_GRAVATAR = true ENABLE_FEDERATED_AVATAR = false [session] PROVIDER = file COOKIE_SECURE = true COOKIE_NAME = git_session [log] MODE = file LEVEL = Info ROOT_PATH = /opt/gitea/log [security] INSTALL_LOCK = true SECRET_KEY = *** INTERNAL_TOKEN = *** IMPORT_LOCAL_PATHS = false [other] SHOW_FOOTER_BRANDING = false SHOW_FOOTER_VERSION = false SHOW_FOOTER_TEMPLATE_LOAD_TIME = false [oauth2] JWT_SECRET = *** Working instance: app.iniAPP_NAME = git @ otherdomain.example.com RUN_MODE = prod [repository] ROOT = /data/git/repositories [repository.upload] TEMP_PATH = /data/gitea/uploads [server] APP_DATA_PATH = /data/gitea SSH_DOMAIN = otherdomain.example.com HTTP_PORT = 3000 ROOT_URL = https://otherdomain.example.com/ DISABLE_SSH = false SSH_PORT = 2222 SSH_LISTEN_PORT = 22 [database] DB_TYPE = mysql HOST = /var/run/mysqld/mysqld.sock NAME = gitea USER = gitea PASSWD = *** [session] PROVIDER_CONFIG = /data/gitea/sessions [mailer] ENABLED = false [picture] AVATAR_UPLOAD_PATH = /data/gitea/avatars DISABLE_GRAVATAR = true ENABLE_FEDERATED_AVATAR = false [log] MODE = file LEVEL = Warn ROOT_PATH = /data/gitea/log [security] INSTALL_LOCK = true SECRET_KEY = *** INTERNAL_TOKEN = *** [other] SHOW_FOOTER_BRANDING = false SHOW_FOOTER_VERSION = false SHOW_FOOTER_TEMPLATE_LOAD_TIME = false [oauth2] JWT_SECRET = *** |
I've done some additional testing on the first of the above instances. Two repositories (real world, no test dummies), both 1 Slack webhook and 1 Gitea webhook. Same configuration, same owner, same commit (dummy file on new temp-branch). One repository (the slightly older one) behaves correcly, the other triggers twice. Both logs (Trace level) attached: I cannot debug in that instance, as it is live and prod, but I had a look into the code. gitea/modules/webhook/deliver.go Line 152 in 2b0e4e0
webhooks.go in v1.10: Line 930 in f0f48e0
|
I take a look at two implementation on master and v1.10. It's the same. |
I've updated from 1.10.1 to 1.10.2 today. No change. However by chance I've found the origin of the bug, because I have migrated my Gitea to a different directory structure and had to re-synchronize all hook scripts. Apparently there are 2 identical hook files for pre- and post-receive phase, one named gitea (the correct one) and one named like the phase.
(not for update) Last modification of the "wrong" scripts is somewhere back in 2017, the gitea scripts are modified today (I've triggered the "synchronize ... hooks for all repositories" task). So the hook is really triggered twice externally. |
|
I know. Content was exactly the same for all affected repos and I‘m pretty sure I never configured this and none of the collaborators knew the binary/config paths... 🤔 |
If the content in |
Same here and same issue. My Drone is going crazy and begging for mercy... |
Then you need to remove these unnecessary duplicated hooks. Do you have any idea how they ended up being there? When did you start using Gitea? |
How do I do that automatically? I certainly can't do it manually as this would take hours. What file's content do I have to compare to which other file's one? Is the naming and pathing consistent? Is maybe another method more useful? In my situation I had to do something like this, urgently, which could've caused additional issues, but I can at least push now and the double hooks are a smaller problem than the one described in this thread.
I think it was shortly after 1.0, don't remember really. |
Ok, so it's a longstanding migration issue from that point in time. Sorry about that - ok here's how you remove those double hooks: cd gitea-repositories
for i in */*.git/hooks; do
if test -e "$i/pre-receive.d/pre-receive"; then
diff "$i/pre-receive.d/pre-receive" "$i/pre-receive.d/gitea" > /dev/null && rm "$i/pre-receive.d/pre-receive"
fi
done And similarly for update and post-receive. (Or something like that. Please be aware I'm writing bash on my phone in bed - stick echos in front of those rms before you run it.) |
Thanks for your help. From what I understand, this issue needs a general fix i.e. pull request, anyway? |
I don't think this needs a PR - there's no current bug and the situation cannot occur in new repositories or on new installs. This is a migration issue from early Gitea. We just need to delete the duplicate hooks. Unless we can see that the problem comes back... (Likely some migration script failed for you a number of years ago, which one I don't know.) |
I never really "migrated" in the classic sense, except recently, when the sleeping error woke up. So are all Gitea native hooks now saved as |
You're correct that they're all saved as pre-receive.d/gitea etc. The code is here: gitea/modules/repository/hooks.go Lines 26 to 70 in d92781b
Prior to that it was here: Lines 919 to 963 in 27c6b8f
With the name being gitea since at #1006 when the directories were created. So I don't know where you picked up the pre-receive etc copies as they shouldn't have been put there by Gitea. |
🤷♀ |
Possibly there was some broken migration script?! Anyway have you managed to get rid of the things? |
I ran #6636 (comment) and your #9183 (comment) but it did not change anything, as the scripts don't seem to find anything. I need to investigate that, as I assume, the solution should be pretty much like what was provided here. Well, I fixed it. I manually cd gitea-repositories
find . -name "gitean" -exec rm {} \; I suppose these issues can be closed now? |
[x]
):Description
I deployed gitea in my kubernetes from the docker image of gitea/gitea. I linked the webhook to the created repository and noticed that all events are fired twice (push, create / delete branch and tags, etc.). The pull-request event was triggered as many as 4 times per action, but there is a separate issue for this #9181. In the images below, I pushed a new brunch and received two push and brunch creation events each. Webhook has been configured in both "All Events" and "Push events" mode. In both cases, push events arrived twice, and in "All events" mode all events came twice.
Screenshots
The text was updated successfully, but these errors were encountered: