GitLab CI Yaml template dropdown
## What does this MR do?
Make it possible to select a dropdown for an easy start with GitLab CI.
## What are the relevant issue numbers?
Closes#17521
## TODO
- [ ] Backend
- [x] CHANGELOG item
- [x] Fix rubocop failure
- [x] API Support
- [x] New tests
- [x] Add disclaimer to the top of the gitlab-ci.yml
- [ ] Frontend
- [x] New tests
See merge request !4411
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
Remove the annotate gem and delete old annotations
In 8278b763d9 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.
Fixes: #17382
/cc @yorickpeterse
See merge request !4099
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".
Pre-calculate Emoji digests
cc @dzaporozhets @rspeicher
@marin Do you happen to know if we allow users to configure asset hosts anywhere in Omnibus and such? I've not been able to find any reference to "asset_host" so it seems we don't allow this (which is a good thing as this simplifies the code).
See merge request !3458
By pre-calculating the digests we can manually construct the emoji URLs,
removing the need for using Rails' asset URL helpers. The reason we
don't want to use these helpers for Emojis is two-fold:
1. Rails' image_url() method is slow, really slow. For one it _might_
have to calculate digests but it also performs a lot of other
intensive operations (judging by the source code and based on
measuring timings).
2. We have a lot of Emoji which coupled with the above can result in it
taking minutes to load Emoji autocomplete data.
Using this pre-calculation setup generating the digests takes around 7
seconds (including the time it takes to start Rails/Rake), and only
around 600 milliseconds to load _all_ the autocomplete data of a project
(measured locally).
This commit _does_ change the Emoji URLs from absolute to relative URLs
as these are much easier to generate.
To update the Emoji data simply run:
rake gemojione:digests
Then commit any changes.
Fixesgitlab-org/gitlab-ce#14009
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 a `gemojione:sprite` Rake task
This task will generate a standard and Retina sprite of all of the
current Gemojione Emojis, with the accompanying SCSS map.
It will not appear in `rake -T` output, and the dependent gems are not
included in the Gemfile by default, because this task will only be
needed occasionally.
See merge request !3130
This task will generate a standard and Retina sprite of all of the
current Gemojione Emojis, with the accompanying SCSS map.
It will not appear in `rake -T` output, and the dependent gems are not
included in the Gemfile by default, because this task will only be
needed occasionally.
[ci skip]
We did a small experiment to see how a full scan of the Redis keys on
gitlab.com speeds up as we increase the batch size. The values on the
right are time in seconds for a full scan (no delete operations).
count: 10); 284.500529021
count: 100); 86.21216934
count: 1_000); 60.931676195
count: 10_000); 60.96355610
count: 100_000); 62.378172541
It looks like 1,000 is a good number.