After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796644 - Add git update hook to Tracker git repo
Add git update hook to Tracker git repo
Status: RESOLVED FIXED
Product: sysadmin
Classification: Infrastructure
Component: Git
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Sysadmins
GNOME Sysadmins
Depends on:
Blocks:
 
 
Reported: 2018-06-21 16:21 UTC by Carlos Garnacho
Modified: 2018-06-22 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Update hook (1.92 KB, application/x-shellscript)
2018-06-21 16:21 UTC, Carlos Garnacho
Details

Description Carlos Garnacho 2018-06-21 16:21:40 UTC
Created attachment 372746 [details]
Update hook

I would like to request adding the (attached) git update hook to GNOME/tracker.git. The script enforces that any change to an specific set of files must also be accompanied by a bump (well, change) to a version #define. 

Not doing so may have ill effects in user setups, it uses(d) to happen automatically, but this stood as a showstopper to fully switch to meson. I can give up the automation, but I still want a safety net.
Comment 1 Andrea Veri 2018-06-22 07:35:21 UTC
Carlos,

this looks to me more a pre-receive hook than an update one as we want this to fail BEFORE the git push succeeds. Can you please confirm?
Comment 2 Carlos Garnacho 2018-06-22 09:09:26 UTC
Hmm, it was kinda deliberate, from pre-receive docs in https://git-scm.com/docs/githooks:

"If the hook exits with non-zero status, none of the refs will be updated. If the hook exits with zero, updating of individual refs can still be prevented by the update hook."

I liked the per-ref nature, but it's probably a bit unimportant (eg. allowing to push WIP work while forbidding on master/stable branches). If you deem pre-receive a better place for that, I can change the script to take input as pre-receive hooks do.
Comment 3 Andrea Veri 2018-06-22 11:01:53 UTC
Carlos, that's fine, for a moment I thought update was being executed after a successful push action happened, that's definitely not the case as per docs above. Landed the hook, please test!
Comment 4 Carlos Garnacho 2018-06-22 11:17:20 UTC
Works nicely :).

$ git push origin carlosg/git-hook-test 
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 456 bytes | 228.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: Parser changes found without bump to TRACKER_PARSER_VERSION, not pushing
remote: Revision(s) affected:
remote: 7cdbde70108d3a37430eb15e78c73ae800f10782
remote: error: hook declined to update refs/heads/carlosg/git-hook-test
To gitlab.gnome.org:GNOME/tracker.git
 ! [remote rejected]     carlosg/git-hook-test -> carlosg/git-hook-test (hook declined)
error: failed to push some refs to 'git@gitlab.gnome.org:GNOME/tracker.git'

Thanks!
Comment 5 Andrea Veri 2018-06-22 15:01:22 UTC
Carlos,

on a side note seems committing via the web UI fails when the hook is there (GIT_DIR seems to come undefined when a commit happens via the web UI instead of the cli), please have a look at [1].

[1] https://gitlab.gnome.org/Infrastructure/GitLab/issues/288