Move reply by email docs to a new location
## What does this MR do?
Move reply by email docs to a new location.
Part of https://gitlab.com/gitlab-org/gitlab-ce/issues/3349
## Moving docs to a new location?
See the guidelines: http://docs.gitlab.com/ce/development/doc_styleguide.html#changing-document-location
- [ ] Make sure the old link is not removed and has its contents replaced with a link to the new location.
- [ ] Make sure internal links pointing to the document in question are not broken.
- [ ] Search and replace any links referring to old docs in GitLab Rails app, specifically under the `app/views/` directory.
- [ ] If working on CE, submit an MR to EE with the changes as well.
See merge request !6517
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.
We never add things `into` projects, we just add them `to` projects. So how about we rename this to `add_users_to_project`.
Rename `projects_ids` to `project_ids` by following the convention of rails.
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.
Added checks for migration downtime
This adds a set of checks that check/list which migrations require downtime (or not). It also comes with a CI task that fails should a migration not be tagged properly.
Fixes#14545
See merge request !4911
These new checks can be used to check if migrations require downtime or
not (as tagged by their authors). In CI this compares the current branch
with master so migrations added by merge requests are automatically
verified.
To check the migrations added since a Git reference simply run:
bundle exec rake gitlab:db:downtime_check[GIT_REF]
Fix restore warning message
## What does this MR do?
Fix the restore Rake task so it properly outputs the database warning. This is a pretty important warning and it was not even being output. After this fix, the output looks like the screenshot below.
See merge request !4980
This commit builds on the groundwork in
ee008e300b1ec0abcc90e6a30816ec0754cea0dd, which refactored the backend
so the same code could be used for new dropdowns. In this commit its
used for templates for the `.gitlab-ci.yml` files.
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
Valery Sizov
Rémy Coutable
Achilleas Pipinellis
Justin DiPierro
bogdanvlviv
Robert Speicher
Herminio Torres
Stan Hu
Drew Blessing
Robert Speicher
M. Ricketts
Yorick Peterse
Alejandro Rodríguez
James Lopez
Z.J. van de Weg
Connor Shea
Daniel Beyer
DJ Mountney
Kamil Trzcinski
Jazz
Douwe Maan
ashleys
Marin Jankovski