GitLab hooks/post-receive not called by SubGit 3.3.11

Hi,

Something changed between SubGit 3.3.10 and 3.3.11 that results in hooks/post-receive not being called when installed into a GitLab 13.10.1 hashed repository.

To verify, I uninstalled 3.3.11, reinstalled 3.3.10, ran “subgit install …” on one of the affected repositories to roll back to 3.3.10, then pushed a commit to the sync’d Subversion repository. The post-receive hook is called as expected.

The problem happens regardless of the states of “gitlab.triggerSvnPostReceive” or “svn.triggerSvnPostReceive”.

As an aside, up to this point I’ve successfully used the post-receive hook to ensure merge requests are updated properly, and to work around the issue reported here:

Thank you,
Demian Nave

Hello Demian,

may I ask you to share the SubGit configuration file (/subgit/config, the Git configuration file from the affected repository (/config), listing of the directory /subgit/.run and the gitlab file from that directory if that is present. This should be taken from an affected 3.3.11 repository.

Thank you in advance!

Hi Ildar,

Apologies for the delay, I’ve only just now been able to get back to this, as I’d already downgraded our repos to SubGit 3.3.10 to get back to a working state.

Fortunately, I needed to create a new mirror, so I used SubGit 3.3.11. For this repository, ‘post-receive’ was called after SubGit was installed, but GL_REPOSITORY was empty until I pushed a dummy change to GitLab from a clone (https://issues.tmatesoft.com/issue/SGT-1267).

I then tried upgrading an existing mirror to SubGit 3.3.11, one for which no Subversion commits were made after mirroring, so the hook was never called. This repo exhibited the same behavior: the hook was called after upgrading, but with an empty GL_REPOSITORY until I pushed a dummy commit to GitLab.

Lastly, I tried again to upgrade the mirror for which SubGit stopped calling the hook (the original subject of this thread). Inexplicably, the hook was called after the upgrade, and pushing a dummy commit resulted in the correct behavior for GL_REPOSITORY.

I am at a loss here. However, as there seems to be a path forward to do the upgrades, and there are no longer any log entries showing the original failure, I’m okay with blaming this on gremlins (or myself).

I will make sure to snapshot the info you requested if the error crops up during the remaining upgrades. In the meantime, if there is any more info I can provide, please let me know.

Thank you,
Demian

Hi Demian,

the GL_REPOSITORY is being fulfilled after the very first push to a SubGit repository in GitLab environment, indeed, as there is no other way to get this information from GitLab, so this behavior is expected. It is also expected that the hooks are being invoked, so that was pretty strange they were not and it would be really great to collect all those logs if the issue happens again, it would help us a lot to understand what’s happening there.
Glad to know, however, that everything is working fine now, hope it will continue working this way only :)