Skip to content

Git hook blocks creation of annotated tag via UI

Summary

When having a Git update hook installed the creation of an annotated tag via the UI is rejected. The output of the hook indicates that the tag is a lightweight tag despite having a message set.

Steps to reproduce

  1. Install the attached Git update hook block-unannotated-tags.sh by coping it into the gitlab-shell/hooks/update.d directory and making the script excutable. The hook script is a stripped down version of the Git upstream update.sample hook.
  2. Create some commits.
  3. Create a new annotated tag via the New Tag page by giving the tag name test-tag and a message Test message.
  4. The hook reports: The un-annotated tag `test-tag` is not allowed in this repository. Use `git tag [ -a | -s ]` for tags you want to propagate.

Example Project

Not applicable, GitLab.com doesn't seem to allow the creation Git hooks for users.

What is the current bug behavior?

  • When creating a tag via the UI with a tag name and a tag message a lightweight tag is created and the tag creation is prevented by the Git update hook.

What is the expected correct behavior?

  • When creating a tag via the UI with a tag name and a tag message an annotated tag is created and the tag creation is accepted by the installed Git update hook.

Relevant logs and/or screenshots

The production.log didn't show any related entries.

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:		
Current User:	git
Using RVM:	yes
RVM Version:	1.29.2
Ruby Version:	2.3.3p222
Gem Version:	2.6.12
Bundler Version:1.15.3
Rake Version:	10.5.0
Redis Version:	3.2.3
Git Version:	2.13.3
Sidekiq Version:5.0.0
Go Version:	unknown

GitLab information
Version:	9.4.1
Revision:	6678b4e5a6
Directory:	/home/git/gitlab
DB Adapter:	mysql2
URL:		http://
HTTP Clone URL:	http:///some-group/some-project.git
SSH Clone URL:	git@:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	no


GitLab Shell
Version:	5.3.1
Repository storage paths:
  • default: /home/git/repositories Hooks: /home/git/gitlab-shell/hooks Git: /home/git/usr/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab Shell ...

GitLab Shell version >= 5.3.1 ? ... OK (5.3.1)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
5/3 ... ok
5/6 ... ok
5/7 ... ok
5/8 ... ok
5/9 ... ok
5/10 ... ok
5/11 ... ok
7/12 ... ok
7/13 ... ok
7/14 ... ok
7/15 ... ok
16/18 ... ok
8/20 ... ok
8/23 ... ok
7/24 ... ok
7/25 ... ok
8/28 ... ok
7/29 ... ok
7/30 ... ok
8/31 ... ok
11/32 ... ok
10/33 ... ok
7/34 ... ok
12/35 ... ok
12/36 ... ok
12/37 ... ok
16/38 ... ok
7/39 ... ok
7/41 ... ok
16/42 ... ok
12/44 ... ok
11/45 ... ok
11/46 ... ok
11/47 ... ok
12/48 ... ok
15/49 ... ok
15/50 ... repository is empty
7/51 ... ok
16/52 ... ok
7/53 ... ok
7/55 ... ok
12/56 ... ok
7/57 ... ok
16/58 ... ok
15/59 ... ok
Running /home/git/gitlab-shell/bin/check
Check GitLab API access: OK
Access to /home/git/.ssh/authorized_keys: OK
Send ping to redis server: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Sidekiq ...


Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Checking Reply by email ...


Reply by email is disabled in config/gitlab.yml


Checking Reply by email ... Finished


Checking LDAP ...


LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... no
Try fixing it:
Install the init script
For more information see:
doc/install/installation.md in section "Install Init Script"
Please fix the error above and rerun the checks.
Init script up-to-date? ... can't check because of previous errors
Projects have namespace: ...
5/3 ... yes
5/6 ... yes
5/7 ... yes
5/8 ... yes
5/9 ... yes
5/10 ... yes
5/11 ... yes
7/12 ... yes
7/13 ... yes
7/14 ... yes
7/15 ... yes
16/18 ... yes
8/20 ... yes
8/23 ... yes
7/24 ... yes
7/25 ... yes
8/28 ... yes
7/29 ... yes
7/30 ... yes
8/31 ... yes
11/32 ... yes
10/33 ... yes
7/34 ... yes
12/35 ... yes
12/36 ... yes
12/37 ... yes
16/38 ... yes
7/39 ... yes
7/41 ... yes
16/42 ... yes
12/44 ... yes
11/45 ... yes
11/46 ... yes
11/47 ... yes
12/48 ... yes
15/49 ... yes
15/50 ... yes
7/51 ... yes
16/52 ... yes
7/53 ... yes
7/55 ... yes
12/56 ... yes
7/57 ... yes
16/58 ... yes
15/59 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.3 ? ... yes (2.3.3)
Git version >= 2.7.3 ? ... yes (2.13.3)
Active users: ... 10


Checking GitLab ... Finished

The host is a CentOS 7 installation and uses systemd as init manager. The related GitLab init scripts are implemented as gitlab-*.services.

Edited by Marcel Metz