Unfortunately rake doesn't have nested context,
everything just runs on a main rake object.
This is probably due to compatibility issue,
but anyway, we could just extend the object.
Make the `gitlab:gitlab_shell:check` task check that the repositories storage
path are owned by the `root` group
Signed-off-by: Rémy Coutable <remy@rymai.me>
This will be necessary when adding gitaly settings. This version
doesn't make any functional changes, but allows us to include this
breaking change in 9.0 and add the needed extra settings in the future
with backwards compatibility
It was previously possible for invalid credential errors to go unnoticed
in this task. Users would believe everything was configured correctly and
then sign in would fail with 'invalid credentials'. This adds a specific
bind check, plus catches errors connecting to the server. Also, specs :)
This prevents the following message from appearing whenever running a
Rake task:
Instance method "run" is already defined in Object, use generic
helper instead or set StateMachines::Machine.ignore_method_conflicts
= true.
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
A few things to note:
- The IncomingEmail feature is now enabled even without a
correctly-formatted sub-address
- Message-ID for new thread mail are kept the same so that subsequent
notifications to this thread are grouped in the thread by the email
service that receives the notification
(i.e. In-Reply-To of the answer == Message-ID of the first thread message)
- To maximize our chance to be able to retrieve the reply key, we look
for it in the In-Reply-To header and the References header
- The pattern for the fallback reply message id is "reply-[key]@[gitlab_host]"
- Improve docs thanks to Axil
Add user repository integrity check rake task
Corrupt repositories and stuck lock files can cause weird issues in
GitLab. Often we know which user is having these problems and then we
have to go hunt down which repository is causing it. Several times
recently that involved me running queries in the rails console to get
an array of projects and then writing a quick Ruby script to loop
through and run `git fsck`. This last time I also had to check for the
existence of `config.lock` and ref lock files.
This rake task will eliminate all of those steps and allow an admin to
simply specify a username.
I also added the lock file checks to the existing `gitlab:repo:check`
task which goes through all projects.
See merge request !2080
Gabriel Mazetto
Sean McGivern
Nick Thomas
Lin Jen-Shin
Douwe Maan
Rémy Coutable
Sebastian Reitenbach
Alejandro Rodríguez
Drew Blessing
Achilleas Pipinellis
bogdanvlviv
Robert Speicher
M. Ricketts
Connor Shea
Jazz
Marin Jankovski
Stan Hu
Robert Speicher
Benny Schimmer
Douwe Maan
Jacob Vosmaer