-
-
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
gpg signing not working for PR in organisition #24503
Comments
Hi all, have you reproduce the bug? |
Gitea should use the .gitconfig in But even if you modify that .gitconfig it might still not work due to this bug I found in Forgejo: https://codeberg.org/forgejo/forgejo/issues/869 If that bug also exists in Gitea's current development code, it should be fixed before the 1.20 release! |
At least "my" bug seems to be fixed in 1.20 rc0 and git.HOME_PATH now defaults to the correct path - @8mccm8 might be worth trying out that version, maybe your bug is fixed as well? |
What's your By default, And , do you have |
# The problem There were many "path tricks": * By default, Gitea uses its program directory as its work path * Gitea tries to use the "work path" to guess its "custom path" and "custom conf (app.ini)" * Users might want to use other directories as work path * The non-default work path should be passed to Gitea by GITEA_WORK_DIR or "--work-path" * But some Gitea processes are started without these values * The "serv" process started by OpenSSH server * The CLI sub-commands started by site admin * The paths are guessed by SetCustomPathAndConf again and again * The default values of "work path / custom path / custom conf" can be changed when compiling # The solution * Use `InitWorkPathAndCommonConfig` to handle these path tricks, and use test code to cover its behaviors. * When Gitea's web server runs, write the WORK_PATH to "app.ini", this value must be the most correct one, because if this value is not right, users would find that the web UI doesn't work and then they should be able to fix it. * Then all other sub-commands can use the WORK_PATH in app.ini to initialize their paths. * By the way, when Gitea starts for git protocol, it shouldn't output any log, otherwise the git protocol gets broken and client blocks forever. The "work path" priority is: WORK_PATH in app.ini > cmd arg --work-path > env var GITEA_WORK_DIR > builtin default The "app.ini" searching order is: cmd arg --config > cmd arg "work path / custom path" > env var "work path / custom path" > builtin default ##⚠️ BREAKING If your instance's "work path / custom path / custom conf" doesn't meet the requirements (eg: work path must be absolute), Gitea will report a fatal error and exit. You need to set these values according to the error log. ---- Close go-gitea#24818 Close go-gitea#24222 Close go-gitea#21606 Close go-gitea#21498 Close go-gitea#25107 Close go-gitea#24981 Maybe close go-gitea#24503 Replace go-gitea#23301 Replace go-gitea#22754 And maybe more # Conflicts: # cmd/web.go
Description
Hi,
I created an organization called team and a one repository ansible. I cloned this repo in my account jeanmichel and my goal is to signed the PR request into the origin repo team/ansible.git from mine for sure!
All, my personal commit are signed no issue BUT my PR are not signed.
During the process gitea can read the gpg key and tell me it will be signed:
but not and return an HTTP 500
I tried also with:
config added in
I'm pretty sure I missed something but I tried different configuration all gpg in gitconfig but always the same issue...
thanks for your feed back
thx for @techknowlogick discord support
Gitea Version
1.19.0 and 1.19.3
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
2.31.1
Operating System
Red Hat Enterprise Linux release 8.7 (Ootpa)
How are you running Gitea?
simple systemd start
fresh install and all repo are created with migration tool from 1.14.0, no package,
and debuging in consol
Database
MySQL
The text was updated successfully, but these errors were encountered: