problem with git push

[Łukasz Michalski]

On 21/11/2020 20.11, Thomas De Schampheleire wrote:
> Hello,
>
> El vie., 20 nov. 2020 a las 15:50, Łukasz Michalski (<lm at zork.pl>) escribió:
>> On 20/11/2020 15.42, Mads Kiilerich wrote:
>>> On 11/20/20 9:49 AM, Łukasz Michalski wrote:
>>>> On 19/11/2020 20.53, Mads Kiilerich wrote:
>>>>> On 11/19/20 4:31 PM, Łukasz Michalski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have a problem with one of git repos. When I try to push changes I got "remote rejected":
>>>>>>
>>>>>> [zork at serenity filebench]$ git push zork
>>>>>> Password for 'https://zork@XXXXXXXXXXXX':
>>>>>> Enumerating objects: 15, done.
>>>>>> Counting objects: 100% (15/15), done.
>>>>>> Delta compression using up to 8 threads
>>>>>> Compressing objects: 100% (8/8), done.
>>>>>> Writing objects: 100% (8/8), 3.17 KiB | 1.58 MiB/s, done.
>>>>>> Total 8 (delta 7), reused 0 (delta 0), pack-reused 0
>>>>>> To https://XXXXXXXXXXXX
>>>>>>    ! [remote rejected] branch -> branch (pre-receive hook declined)
>>>>>> error: failed to push some refs to 'https://XXXXXXXXXXXX'
>>>>>>
>>>>>> Kallithea  0.6.2 on Arch Linux.
>>>>>>
>>>>>> What can I do to resolve this issue? I already tried to increase log level but I cannot find any clues in logs.
>>>>> It works for other repos - just not this one?
>>>>>
>>>>> The pre-receive hook is really not doing anything and should never reject pushes. I guess the hooks (for this repo?) isn't installed correctly? Inspect and compare hooks/post-receive for working and non-working repos. Or try to reinstall all hooks in Admin/Settings/Remap and Rescan/Install Git hooks + Overwrite existing Git hooks.
>>>>>
>>>>> It might be a very fundamental problem (such as finding the right Python interpreter to run the hook) so I doubt Kallithea logging could say anything. But perhaps the web server error log has something.
>>>>>
>>>>> /Mads
>>>>>
>>>> Rescan+Overwrite helped. Thanks!
>>>>
>>>> I also upgraded kallithea to 0.6.2 changing python version from 3.7 to 3.8 (by creating new venv).
>>>
>>> Great it works.
>>>
>>> Should the documentation be improved to clarify the importance of re-installing git hooks after upgrading Kallithea or Python? Where and how would you suggest phrasing it?
>>>
>>> I don't know how we can improve this handling. We rely on Git functionality. If you modify hooks/pre-receive to invoke sys.stdin.write or sys.stderr.write or cause an exception (for example by adding an invalid import), you will see that as "remote:" lines on the client side. But if you modify the first line with #! to point at something that doesn't work, Git will be silent - not even a "bad interpreter" message as the shell would do.
>>>
>>> We could perhaps change the hooks to *always* write something, such as "rejected by Kallithea hook" or "accepted by Kallithea hook" ... and if there is no such message, we can know that the hook failed badly. But that wouldn't be explicit and obvious ... and we did figure it out anyway.
>>>
>>> /Mads
>>>
>> I would automate the most common path - python upgrade.
>>
>> Store python version somewhere in db when hooks are installed.
>> Check if hooks needs reinstall on startup.
> I don't think that the Python version is the crucial element here.
> Rather, any change in the virtualenv path would yield this problem.
> Changing the virtualenv path also has impact in other places: it
> causes a new path to kallithea-cli, which has impact on e.g. the
> authorized_keys file for SSH repository access.
>
> Having a check on startup like you suggest could perhaps be done: scan
> the git hooks, authorized keys, and perhaps other places, to check
> whether python and other paths point to the running instance, giving a
> warning if it is not the case.
>
I did not change venv path. When upgrading from 3.7 to 3.8 i removed venv dir and recreated it in the same location.
Then I created frontend, default config file and manually merged all changes from old config file to new one.

I think that if kallithea installs it's own components in repositories then kallithea should check them on startup and try to reinstall if there is any problem. If reinstall fails then it is time to warn user.

I agree that many things can change and break something, but simple python upgrade should work out of the box.

Regards,
Łukasz