Dumping too many jobs in the same queue (e.g. the "default" queue) is a
dangerous setup. Jobs that take a long time to process can effectively
block any other work from being performed given there are enough of
these jobs.
Furthermore it becomes harder to monitor the jobs as a single queue
could contain jobs for different workers. In such a setup the only
reliable way of getting counts per job is to iterate over all jobs in a
queue, which is a rather time consuming process.
By using separate queues for various workers we have better control over
throughput, we can add weight to queues, and we can monitor queues
better. Some workers still use the same queue whenever their work is
related. For example, the various CI pipeline workers use the same
"pipeline" queue.
This commit includes a Rails migration that moves Sidekiq jobs from the
old queues to the new ones. This migration also takes care of doing the
inverse if ever needed. This does require downtime as otherwise new jobs
could be scheduled in the old queues after this migration completes.
This commit also includes an RSpec test that blacklists the use of the
"default" queue and ensures cron workers use the "cronjob" queue.
Fixesgitlab-org/gitlab-ce#23370
Rename users routing from /u/:username to /users/:username for
consistency with other routes
Renames /u/:username to /users/:username
To follow consistency with other routes (like groups) and
UsersController name.
Now when you can use `/:username` for accessing user page there is no
need in shortcut like `/u/`
See merge request !6851
Added CC0 license to list of licenses
Adds a "license" (actually a deed, because its a dedication to the public domain) to the appropriate place in the documentation.
It adds another relevant license to our documentation.
See merge request !6622
Added performance guidelines for new MRs
## What does this MR do?
This MR adds a set of guides that should be followed by merge request authors.
## Are there points in the code the reviewer needs to double check?
Spelling, grammar, etc
## Why was this MR needed?
There is no set of guidelines one should follow when submitting merge requests. This leads to developers at times disregarding performance. This in turn results in performance specialists having to clean up the mess, or production engineers being woken up in the middle of the night because the database is on fire.
## Does this MR meet the acceptance criteria?
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- Tests
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
cc @DouweM @rspeicher @pcarranza @dzaporozhets
See merge request !5905
To clarify what's meant by "from a logical perspective" here, I
consulted Python's PEP8 style guide, which provides some helpfully
precise language:
> Extra blank lines may be used (sparingly) to separate groups of
> related functions. Blank lines may be omitted between a bunch of
> related one-liners (e.g. a set of dummy implementations).
https://www.python.org/dev/peps/pep-0008/#blank-lines
I adapted this passage to the existing language for the newline rule.
These guidelines cover the performance requirement for newly submitted
merge requests. These guidelines are put in to place to prevent merge
requests from negatively impacting GitLab performance as much as
possible.
Update UI Guide with SVG guidelines
This addition to the guide is to provide some guidelines to UX designers when exporting SVGs. Please let me know if anything is unclear or if you any improvements so we can document it clearly for everyone.
cc / @hazelyang @cperessini @dimitrieh @connorshea @annabeldunstone @dzaporozhets
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ee/issues/872
See merge request !5748