Fix bug with SQL syntax error during backup restoration
## What does this MR do?
It properly escapes the table name in the `DROP TABLE IF EXISTS ...` statement used during restore of a backup.
## Are there points in the code the reviewer needs to double check?
Please check compatibility with PostgreSQL
## Why was this MR needed?
Fix an issue with backups can not be restored if MySQL is used as database for GitLab.
## What are the relevant issue numbers?
#15259
## Screenshots (if relevant)
-
See merge request !4318
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
Using db:reset ensures existing tables are first dropped. This in turn
ensures that we can drop tables regardless of any foreign key
constraints. While CE currently doesn't have any foreign keys EE defines
the following relation:
remote_mirrors.project_id -> projects.id
MySQL will complain whenever you try to drop the "projects" table first
even when using "DROP TABLE ... CASCADE".
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
- Offloads uploading to GitLab Workhorse
- Use /authorize request for fast uploading
- Added backup recipes for artifacts
- Support download acceleration using X-Sendfile
Stan Hu
Connor Shea
Daniel Beyer
DJ Mountney
Kamil Trzcinski
Zeger-Jan van de WegandAlfredo Sumaran
JazzandLudovic Perrine
Drew Blessing
Yorick Peterse
Rémy Coutable
Douwe Maan
ashleys
Marin Jankovski
Achilleas Pipinellis
Robert Speicher
Robert Speicher
Douwe Maan
Jacob Vosmaer
Zeger-Jan van de Weg
Marin Jankovski
Benny Schimmer
Zeger-Jan van de WegandZeger-Jan van de Weg