| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
them to be configurable
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Refactor project routing
## What does this MR do?
Refactor project routing:
* split on multiple files
* improve routing order
## Why was this MR needed?
It makes it easier to maintain and modify project routing
## What are the relevant issue numbers?
Extracted from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7121
See merge request !7329
|
| |
| |
| |
| |
| |
| |
| | |
* split on multiple files
* improve routing order
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Refactor namespace regex
Reuse existing namespace regex constant in routing
See merge request !7336
|
| |/
| |
| |
| | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|\ \
| | |
| | |
| | |
| | | |
Set default Sidekiq retries to 3
See merge request !7294
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
By default, Sidekiq will retry 25 times with an exponential backoff.
This may result in jobs retrying for up to 21 days. Most Sidekiq
failures occur when attempting to connect to external services -
Project service hooks, web hooks, mailers, mirror updates, etc.
We should set a default retry of 3, and if that's not sufficient
individual workers can override this in the worker class.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Refactor group routing
## What does this MR do?
Refactor group routing:
* separate controller actions from nested resources
* prepare group routing for nested namespaces support
## Why was this MR needed?
So when we introduce nested groups support we need to only change `:id` to `*id`
## What are the relevant issue numbers?
Extracted from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7121
See merge request !7328
|
| |/
| |
| |
| |
| |
| |
| | |
* separate controller actions from nested resources
* prepare group routing for nested namespaces support
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|\ \
| | |
| | |
| | |
| | | |
Use separate email-friendly token for incoming email
See merge request !5914
|
| | |
| | |
| | |
| | | |
reactivates all tests and writes more tests for it
|
| |/
| |
| |
| | |
email token be reset
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the code used for processing commits from GitPushService to
its own Sidekiq worker: ProcessCommitWorker.
Using a Sidekiq worker allows us to process multiple commits in
parallel. This in turn will lead to issues being closed faster and cross
references being created faster. Furthermore by isolating this code into
a separate class it's easier to test and maintain the code.
The new worker also ensures it can efficiently check which issues can be
closed, without having to run numerous SQL queries for every issue.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Support for post deployment migrations
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/22133
See merge request !6572
|
| |
| |
| |
| |
| |
| |
| |
| | |
These are regular Rails migrations that are executed by default. A user
can opt-out of these migrations by setting an environment variable
during the deployment process.
Fixes gitlab-org/gitlab-ce#22133
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Sidekiq client API adds an entry to the Sidekiq "queues" list,
but mail_room and gitlab-shell use redis-rb directly to insert jobs
into Redis and thus do not make an extra "sadd" call to Redis
each time a job is inserted. To make it possible to monitor
these queues via the API, add an initialization step to
set up the list at startup.
Closes gitlab-com/infrastructure#682
|
|\ \
| | |
| | |
| | |
| | | |
Blacklist the OSL 3.0 license
See merge request !7171
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Remove unreferenced LFS objects from DB and fs
Fixes #3666
See merge request !5901
|
| | | |
|
|/ /
| |
| |
| | |
This prevents VueJS being included in application.js & therefore included on everypage
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
Jira refactoring to jira gem
part of gitlab-org/gitlab-ee#1008
Original MR: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2572/commits
See merge request !6598
|
| |
| |
| |
| | |
Code improvements, bug fixes, finish documentation and specs
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Revert "Revert "Change "Group#web_url" to return "/groups/twitter" rather than "/twitter".""
Looks like I accidently reverted https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7035 although I did not want to . This MR reverts my revert.
See merge request !7127
|
| |/
| |
| |
| |
| |
| | |
than "/twitter".""
This reverts commit 9dbd5b3cfad10b214ae5ef27c39246bbb74a5077.
|
|/ |
|
|
|
|
|
|
| |
"/twitter"."
This reverts commit c81ff152e08d58c13efbd50c40dd2e083ac65083.
|
|
|
|
|
|
|
|
|
|
| |
mail_room was configured to deliver mail to the `incoming_email`
queue while `EmailReceiveWorker` was reading the `email_receiver`
queue. Adds a migration that repeats the work of a previous
migration to ensure all mails that wound up in the old
queue get processed.
Closes #23689
|
|
|
|
|
|
|
|
|
|
| |
By default, ActionMailer uses the "mailers" queue, but this entry
was not included in the list of queues for Sidekiq to use.
For more details:
* https://github.com/plataformatec/devise/wiki/How-To:-Send-devise-emails-in-background-(Resque,-Sidekiq-and-Delayed::Job)
* http://guides.rubyonrails.org/active_job_basics.html
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use separate queues for all Sidekiq workers
## What does this MR do?
This MR updates all workers so that they (mostly) use their own Sidekiq queues. This in turn allows us to monitor queues more accurately and in the future impose queue specific throttles, limits, etc.
This is a critical part we need in 8.13, despite it being so close to release day.
See https://gitlab.com/gitlab-org/gitlab-ce/issues/23370 for more information.
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG.md) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [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 it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/23370
See merge request !7006
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
Fixes gitlab-org/gitlab-ce#23370
|
|/
|
|
|
| |
Bring back the old behaviour which was changed by 6b90ccb9.
Fixes #23527.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Resolve Merge conflicts in editor
## What does this MR do?
This is the second iteration of https://gitlab.com/gitlab-org/gitlab-ce/issues/20344 which now allows to resolve conflicts manually providing an editor to the user.
## Are there points in the code the reviewer needs to double check?
- Previous implementation has been refactored almost from the ground up.
- Also some components like `parallel-conflict-lines` has been optimized to work well with PhantomJS.
- The app and files required files are loaded only when needed. `merge_conflicts_bundle.js` is only loaded in `/<group>/<project>/merge_requests/<Id>/conflicts` only
## Why was this MR needed?
Some MRs were unable to be solved interactively in the UI, with this MR we let the user to manually fix complex merge request conflicts.
## Screenshots (if relevant)
<img src="/uploads/33a016f025bd590b1fc6eeee1ee11626/Screen_Shot_2016-09-19_at_1.39.39_PM.png" width="800">
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] 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)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/20344, https://gitlab.com/gitlab-org/gitlab-ce/issues/3567.
See merge request !6374
|
| | |\ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Use a store base object to manage application state.
- Add a service to handle ajax requests.
- Load code only when needed
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When reading conflicts:
1. Add a `type` field. `text` works as before, and has `sections`;
`text-editor` is a file with ambiguous conflict markers that can only
be resolved in an editor.
2. Add a `content_path` field pointing to a JSON representation of the
file's content for a single file.
3. Hitting `content_path` returns a similar datastructure to the `file`,
but without the `content_path` and `sections` fields, and with a
`content` field containing the full contents of the file (with
conflict markers).
When writing conflicts:
1. Instead of `sections` being at the top level, they are now in a
`files` array. This matches the read format better.
2. The `files` array contains file hashes, each of which must contain:
a. `new_path`
b. `old_path`
c. EITHER `sections` (which works as before) or `content` (with the
full content of the resolved file).
|
| | | | |
|
|\ \ \ \
| |/ / /
| | | |
| | | | |
22191-delete-dynamic-envs-mr
|
| |\ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
to changelog
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
with other routes
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | | | |
|