It used to be the case that GitLab created symlinks for each repository
to one copy of the Git hooks, so these ran when required. This changed
to set the hooks dynamically on Gitaly when invoking Git.
The side effect is that we didn't need all these symlinks anymore, which
Gitaly doesn't create anymore either. Now that means that the tests in
GitLab-Rails should test for it either.
Related: https://gitlab.com/gitlab-org/gitaly/issues/1392#note_175619926
In this commit, some methods that aren't being used
are removed from `Gitlab::Shell`. They are the ff:
- `#remove_keys_not_found_in_db`
- `#batch_read_key_ids`
- `#list_key_ids`
The corresponding methods in `Gitlab::Keys` have been
removed as well.
Fast lookup of authorized SSH keys in the database was ported to CE in
v10.4. This change adds the option to enable the setting via the restore
rake task and assumes yes if the force env variable is set.
Prior to this change, this method was called add_namespace, which broke
the CRUD convention and made it harder to grep for what I was looking
for. Given the change was a find and replace kind of fix, this was
changed without opening an issue and on another feature branch.
If more dynamic calls are made to add_namespace, these could've been
missed which might lead to incorrect bahaviour. However, going through
the commit log it seems thats not the case.
Currently we specify versions for Gitlab-Shell, Workhorse and Gitaly
using version strings, to which we prepend 'v' and assume are tags.
These changes allow branches or tags with other name formats to be
specified by prepending '=' to the version string (á la govendor).
We also simplify the process to reset to the given version (now a
branch or tag): Right now there's a check to supposedly try to avoid
fetching from the remote the version if it already exist locally. But
the previous logic already clones if the directory doesn't exist or
fetches if it does, so this check is pointless. We can safely assume the
version exists once we get to the reset stage.
Previously the gitlab-shell version would never be updated if the directory
existed via the `gitlab🐚install` Rake task. This could lead to
incompatibility issues or random errors.
Colorize is a gem licensed under the GPLv2, so we can’t use it in GitLab without relicensing GitLab under the terms of the GPL. Rainbow is licensed under the MIT license and does the exact same thing as Colorize, so Rainbow was added in place of Colorize.
The syntax is slightly different for Rainbow vs. Colorize, and was updated in accordance.
The gem is still a dependency of Spinach, so it’s included in the development/test environments, but won’t be packaged with the actual product, and therefore doesn’t require we relicense the product.
An attempt at relicensing Colorize was made, but didn’t succeed as the library owner never responded.
Rainbow library: https://github.com/sickill/rainbow
Relevant issue regarding licensing in GitLab's gems: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3775
Before this it would fail because git hooks automatically prepend
things to the path, which can lead the wrong Ruby version to be called
in which dependencies are not installed.
To make sure that this is correct, the forked_merge_requests commented
out test that depends on this change was uncommented.
For that test to pass, it is also necessary to setup the mock server
on port 3001 under test_env.rb.
GitLab Bot
Zeger-Jan van de Weg
Patrick Bajao
Cindy Pallares
Lin Jen-Shin
Ricketts, M (Mike)
Jacob Vosmaer
Gabriel Mazetto
Alejandro Rodríguez
Douwe Maan
Rémy Coutable
Drew Blessing
Justin DiPierro
bogdanvlviv
Stan Hu
Connor Shea
Robert Speicher
Dmitriy Zaporozhets
Marin Jankovski
Andrew Tomaka
Ciro Santilli
Jacob Vosmaer