| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
See https://gitlab.com/gitlab-org/gitlab-ce/issues/24386
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
Grapify triggers API
## What are the relevant issue numbers?
Related to #22928
See merge request !7378
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Grapify milestones API
## What are the relevant issue numbers?
Related to #22928
See merge request !7373
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Grapify runners API
## What are the relevant issue numbers?
Related to #22928
See merge request !7377
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Grapify the session API
## What are the relevant issue numbers?
Related to #22928
See merge request !7381
|
| | |/ / |
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Add api endpoint `/groups/owned`
See merge request !7103
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
API: Return 400 when creating a systemhook fails
Closes #23335
See merge request !7350
|
| | |/ |
|
| | |
| |
| |
| |
| |
| | |
[e44da1c] Add Label API expected keys to tests
[ac929c8] Update Label API documentation
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
See merge request !7014
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
are resolved
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Make specs a bit faster
See merge request !6992
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Expose more info for SystemHooks
See merge request !6964
|
| | | | | |
| | | | |
| | | | |
| | | | | |
[ci skip]
|
| | | | | | |
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |/ / / |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
control flow.
When adding a deploy key that already exists in the project the existing key would not be returned, resulting in an attempt to create a new one, which in turn caused a 500 error due to an ActiveRecord exception.
When adding a deploy key that exists within another project the key would be joined to the project, but would also attempt to create a new one, which resulted in a 400 error due to the key already existing.
Fixes #22741
Fixes #21754
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
| |
| |
| | |
explicitely check for events order
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Grapify the labels API
Add the Grape-DSL to the labels API. Since the input validation messages are checked, two tests are modified slightly.
## What are the relevant issue numbers?
Related to #22928
See merge request !7070
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \
| | | |
| | | |
| | | | |
See merge request !6544.
|
| | |/ /
| | |
| | |
| | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Previously, we were not removing existing access levels before
creating new ones. This is not a problem for EE, but _is_ for CE,
since we restrict the number of access levels in CE to 1.
2. The correct approach is:
CE -> delete all access levels before updating a protected branch
EE -> delete developer access levels if "developers_can_{merge,push}" is switched off
3. The dispatch is performed by checking if a "length: 1" validation is
present on the access levels or not.
4. Another source of problems was that we didn't put multiple queries in
a transaction. If the `destroy_all` passes, but the `update` fails,
we should have a rollback.
5. Modifying the API to provide users direct access to CRUD access
levels will make things a lot simpler.
6. Create `create/update` services separately for this API, which
perform the necessary data translation, before calling the regular
`create/update` services. The translation code was getting too large
for the API endpoint itself, so this move makes sense.
|
