| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| | |
Split out markdown cache storage into a separate method
See merge request !7277
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Fix applying GitHub-imported labels when importing job is interrupted
Closes #24075
See merge request !7245
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Closes #24075
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
See merge request !7014
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add setting to only allow merge requests to be merged when all discussions are resolved
_Originally opened at !6385 by @rodolfoasantos._
- - -
## What does this MR do?
Based on #20968 this merge request adds setting only to allow merge requests to be merged when all discussions are resolved.
## Are there points in the code the reviewer needs to double check?
Check if there are other points to add the resolved discussion setting
## Why was this MR needed?
Add the possibility to configure the project to only accept merge request when all discussions are resolved
## Screenshots
## 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
- [ ] 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)
- [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 #20968
See merge request !7125
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | | |
are resolved
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
GrapeDSL for project hooks
See merge request !6963
|
| | | | | |
|
| | | |/
| |/| |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Update rdoc to `~> 4.2`
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/2814
See merge request !7261
|
| | |/ /
| | |
| | |
| | |
| | | |
This was the only thing using the `sdoc` gem, which was blocking another
gem from updating.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Backport Group API code that was added in EE only
Group API code that was added in EE only. /cc @vsizov
See merge request !7205
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Resolve "Introduce round-robin project creation to spread load over multiple shards"
## What does this MR do?
Allow multiple shards to be enabled in the admin settings page, balancing project creation across all enabled shards.
## Are there points in the code the reviewer needs to double check?
* `f.select ..., multiple: true` isn't the most beautiful UI in the world, but switching to `collection_check_boxes` (or a facsimile thereof) isn't trivial
* Should `pick_repository_storage` be a method of `ApplicationSetting`, or `Project`? It's going to accrete logic over time so perhaps it should be its own class already?
* This is written to avoid the need for a database migration, so it is`serialize :repository_storage` without `, Array`. This is tested, but alternatives include:
* Add a database migration
* Write a custom Coder that will accept a String or Array in `load` and always `dump an Array.
## Why was this MR needed?
## Screenshots (if relevant)
## 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] 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)
- [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?
Closes #24059
See merge request !7273
|
| | | |/ /
| |/| |
| | | |
| | | | |
round-robin between them
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
No matter which environment Gitlab was running as, the admin/logs view
always showed production.log. This commit selects the logfile based
on Rails.env.
- Rename ProductionLogger to EnvironmentLogger
- Make EnvironmentLogger logfile depend on env
- Update spinach test for log tabs
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Expose more info for SystemHooks
See merge request !6964
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now exposed:
- push_events
- tag_push_events
- enable_ssl_verification
- token
Fixes gitlab-org/gitlab-ce#23307
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix symlink vulnerability in Import/Export
Replaces https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2018 made by @james
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/23822
See merge request !2022
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix Import/Export foreign key issue to do with project members
Cleans-up any foreign keys in `ProjectMember` - same as we do with the rest of the models when importing.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/23837 and https://gitlab.com/gitlab-org/gitlab-ce/issues/23739
See merge request !2020
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This MR adds support for the `token` attribute in the project hook API.
Feature requested on a dependant project: https://github.com/gpocentek/python-gitlab/issues/170
See merge request !7220
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The UI allows to define a token to validate payload on the target URL,
this patch adds the feature to the API.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add Rake task to create/repair GitLab Shell hooks symlinks
## What does this MR do?
Adds a Rake task wrapper around `gitlab-shell` `bin/create_hooks` script. This makes it easier for an administrator to repair hooks symlinks without worrying about where repository data is located, etc. Just run this task and it takes care of everything based on current configuration.
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
`bin/create_hooks` was not well-documented. It requires parameters specifying where repository data is located. It also needs to be run by the `git` user. Wrapping it in a Rake task allows us to take current configuration in to account and makes it easier on the administrator.
See merge request !5634
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Because this code resides in lib/ it may be eager loaded. Rails in turn
doesn't define Rails::Generators by default unless you explicitly
require "rails/generators".
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
| | | | | | | |
|
| | |/ / / /
|/| | | |
| | | | |
| | | | | |
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/18096
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
GrapeDSL for branches endpoints
No changelog item as it doesn't change behaviour
Cherry-picket from !6330
See merge request !6630
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix lightweight tags not processed correctly by GitTagPushService
## What does this MR do?
Fix lightweight tags not processed correctly by GitTagPushService
## Are there points in the code the reviewer needs to double check?
No
## Why was this MR needed?
Lightweight tags were being processed incorrectly, causing tag triggers to receive wrong information and not function properly.
## 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)
- [ ] 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)
- [ ] 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 #22271
See merge request !6532
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When we updated gitlab_git to 10.4.1, `tag.target` changed from pointing
to the sha of the tag to the sha of the commit the tag points to. The
problem is that only annotated tags have `object_sha`s, lightweight tags
don't (it's nil), so (only) in their case we still need to use
`tag.target`.
|
| | |/ /
|/| | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Make internal api work with full repo path and name
## What does this MR do?
Make internal api work with full repo path and name
## Why was this MR needed?
So we can pass full repository path on filesystem from gitlab-shell instead of extracted one. We need this for nested groups support where project is can be nested under several groups.
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
See merge request !7148
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Pass user instance to Labels::FindOrCreateService or skip_authorization: true
## What does this MR do?
It fixes a bug described in #23694 when `project.owner` was passed to `Labels::FindOrCreateService`. `Labels::FindOrCreateService` expected a user instance and `project.owner` may return a group as well. This MR makes sure that we either pass a user instance or `skip_authorization: true`.
## Are there points in the code the reviewer needs to double check?
- places where we pass `skip_authorization: true`
## Does this MR meet the acceptance criteria?
- Tests
- [x] 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)
- [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?
Fixes #23694
See merge request !7093
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Do not pass project.owner because it may return a group and Labels::FindOrCreateService
throws an error in this case.
Fixes #23694.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use optimistic locking
## What does this MR do?
Removes the usage of pessimistic locking in favor of optimistic which is way cheaper and doesn't block database operation.
Since this is very simple change it should be safe. If we receive `StaleObjectError` message we will reload object a retry operations in lock.
However, I still believe that we need this one: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7005 as this will reduce a load on Database and FS.
This changes a behavior from:
### Pesimistic locking (previous behavior)
#### For updating
1. SELECT * FOR UPDATE (other updates wait on this)
2. we update ci_pipeline
3. latest_build_status
4. enqueue: (use: transition :created -> :pending)
5. [state_machine] we are in state created, we can go to pending
6. [state_machine] ci_pipeline.status = created
7. [state_machine] ci_pipeline.save
8. [state_machine] after_transition: (if for success): PipelineSuccessWorker on Sidekiq
9. release DB lock
#### If no update is required
1. SELECT * FOR UPDATE (other updates wait on this)
2. we update ci_pipeline
3. latest_build_status
4. we are in pending, we can't transition to pending, because it's forbidden
5. release DB lock
### Optimistic locking (implemented by this MR)
#### For updating
1. latest_build_status
2. enqueue: (use `transition :created -> :pending`)
3. [state_machine] we are in state created, we can go to pending
4. [state_machine] ci_pipeline.status = created
5. [state_machine] ci_pipeline.save
6. [state_machine] [save] where(lock_version: ci_pipeline.lock_version).update_all(status: :created, updated_at: Time.now)
7. [state_machine] [save] unless we_updated_row then raise ObjectInconsistentError
#### If no update is required
1. we update ci_pipeline
2. latest_build_status
3. we are in pending, we can't transition to pending, because it's forbidden
## Why was this MR needed?
We have been seeing a number of problems when we migrated Pipeline/Build processing to Sidekiq. Especially we started seeing a lot of blocking queries.
We used a pessimistic locking which doesn't seem to be required. This effectively allows us to fix our issues with blocked queries by using more efficient method of operation.
## What are the relevant issue numbers?
Issues: https://gitlab.com/gitlab-com/infrastructure/issues/623 and https://gitlab.com/gitlab-com/infrastructure/issues/584, but also there's a bunch of Merge Requests that try to improve behavior of scheduled jobs.
cc @pcarranza @yorickpeterse @stanhu
See merge request !7040
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
