| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
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>
|
| | | | | |
|
| |/ / / |
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We need this to prevent routing error when user access URL like /123
when there is no resource located under such name
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | | | | |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
- Tab between register and sign in forms
- Add individual input validation error messages
- Validate username
- Update many styles for all login-box forms
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add missing routes to make group edits work
6b90ccb9fd changed the routes so that users/groups can be accessed via`/:id`, but the Rails `form_for` method expects to use the `groups#show` path helper for the form action URL. This causes group edits and deletes to fail because the PUT/PATCH/DELETE methods did not exist for `/:id`. This MR adds these methods so that `form_for` continues to work.
Closes #23306
See merge request !6874
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | | |/
| |/|
| | |
| | | |
Closes #23306
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Project members UI
## What does this MR do?
New UI for project members that includes groups.
## Screenshots (if relevant)
### Project members
### Group members
## What are the relevant issue numbers?
Part of #19868
Closes #21320
See merge request !6148
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Used variables in haml for replicated checks
Fixed broken conflict
|
| | |\ \ \ |
|
| | |\ \ \ \ |
|
| | | | | | | |
|
| | | | | | | |
|
| | |_|_|/ /
|/| | | |
| | | | |
| | | | | |
set up frontend polling
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Refactoring Issues Board
## What does this MR do?
This MR aims to minimize conflicts between the CE issues board feature with EE multiple boards feature.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
To avoid a lot of conflicts with EE multiple boards feature.
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] ~~[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)~~
- [x] API support added
- Tests
- [X] Added for this feature/bug
- [ ] All builds are passing
- [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)
- [ ] 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)
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ee/issues/929
https://gitlab.com/gitlab-org/gitlab-ee/issues/1084
See merge request !6727
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Added 'Download' button to snippet view
## What does this MR do?
Adds a `Download` button above a snippet.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
Requested in #22811
## Screenshots (if relevant)
## 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
- [ ] Added for this feature/bug
- [ ] 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)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes #22811
See merge request !6720
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Ability to bulk assign issues to author of merge request
## What does this MR do?
Provides a link to auto-assign issues to the author of a merge request, when they are mentioned as being closed by the MR.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
To help avoid working on a MR without having assigned related issues to self
## What are the relevant issue numbers?
Fixes #18876
## Screenshots (if relevant)
## Tasks
- [x] Refactor or move away from using `BulkUpdateService`
- [x] ~~Consider alternate link message when only a subset of issues will be assigned~~
- [x] Minimize repeated calls to expensive `closes_issues` method
- [x] Move away from using inflector for pluralization and fix flash message
- [x] Change auth `before_action` and fallback to error flash message
- [x] Shouldn't overwrite current assignee if one exists
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [x] ~~API support added~~
- Tests
- [x] Added for this feature/bug
- [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)
See merge request !5725
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Allow browsing branches that end with '.atom'
## What does this MR do?
1. Simplify the regex capture in the routing for the CommitsController
to not exclude the '.atom' suffix. That's a perfectly valid git
branch name, so we shouldn't blow up if we get it.
2. Because Rails now can't automatically detect the request format, add
some code to do so in `ExtractPath` when there is no path. This means
that, given branches 'foo' and 'foo.atom', the Atom feed for the
former is unroutable. To fix this: don't do that! Give the branches
different names!
## Why was this MR needed?
Creating a branch or tag name ending in '.atom' would cause some 500s on that repo.
## What are the relevant issue numbers?
Closes #21955. Related to !5994.
See merge request !6750
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We need to do two things to support this:
1. Simplify the regex capture in the routing for the CommitsController
to not exclude the '.atom' suffix. That's a perfectly valid git
branch name, so we shouldn't blow up if we get it.
2. Because Rails now can't automatically detect the request format, add
some code to do so in `ExtractPath` when there is no path. This means
that, given branches 'foo' and 'foo.atom', the Atom feed for the
former is unroutable. To fix this: don't do that! Give the branches
different names!
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
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
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
[ci skip]
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Precalculate trending projects
## What does this MR do?
This MR changes the trending projects code so that data is precalculated, removing the need for any complex caching mechanisms.
## Why was this MR needed?
Caching of trending data didn't work properly, still leading to queries. Using caching in general would be very hard due to users being able to apply custom filters to the list of trending projects.
See merge request !6749
|
