Also, since Gitaly now takes care of checking for storage paths
existence/accessibility, we can remove those check from the
gitlab:gitlab_shell_check task and advance further into 0 direct disk
approach on gitlab-rails
While reviewing this branch it was noted that this task was broken.
Given the limited value this task brings, and given the fact that much
of the old behaviour has been moved to be automatically fixed, removing
was a good option.
Suggestion in:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20806#note_91261001
These tasks are happening through housekeeping right now, by default
ever 10th push. This removes the need for these tasks.
Side note, this removes one of my first contributions to GitLab, as back
than I introduced these tasks through: 54e6c0045b
Closes https://gitlab.com/gitlab-org/gitaly/issues/768
Direct disk access is done through Gitaly now, so the legacy path was
deprecated. This path was used in Gitlab::Shell however. This required
the refactoring in this commit.
Added is the removal of direct path access on the project model, as that
lookup wasn't needed anymore is most cases.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1111
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
GitLab Bot
Michael Kozono
Zeger-Jan van de Weg
Alejandro Rodríguez
Jacob Vosmaer
Horatiu Eugen Vlad
Lin Jen-Shin
Ben Bodenmiller
🙈 jacopo beschi 🙉
James Lopez
Gabriel Mazetto
Sean McGivern
Nick Thomas
Douwe Maan
Rémy Coutable
Sebastian Reitenbach
Drew Blessing
Achilleas Pipinellis
bogdanvlviv
Robert Speicher
M. Ricketts
Connor Shea
Jazz
Marin Jankovski
Stan Hu