This includes a set of APIs to manipulate container registry.
This includes also an ability to delete tags based on requested
criteria, like keep-last-n, matching-name, older-than.
Check if `X-Forwarded-For` is set before getting the IP of the request,
with this the real IP address of the runner is shown if it's behind a
proxy.
closes https://gitlab.com/gitlab-org/gitlab-ce/issues/53676
[API] Omit `X-Total` and `X-Total-Pages` headers when items count is more than 10,000
Closes#42194 and #52674
See merge request gitlab-org/gitlab-ce!23931
In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15475/diffs, a
significant amount of work went into eliminating N+1 queries in the
/api/groups/:id/projects endpoint. We can reuse the
`Entities::Project.prepare_relation` call on the projects.
In a group with 2,573 projects on GitLab.com, this change significantly
improves performance:
* 18019 SQL queries down to 21
* Time spent in DB: 70 s down to 384 ms
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/49845
Currently if a project is inside a nested group and a user doesn't have
specific permissions for that group but does have permissions on a
parent group the `GET /projects/:id` API call will return the following
permissions:
```json
permissions: { project_access: null, group_access: null }
```
It could also happen that the group specific permissions are of lower
level than the ones the user has in parent groups. This patch makes it
so that the permission returned for `group_access` is the highest from
amongst the hierarchy, which is (ostensibly) the information that the
API user is interested in for that field.
For features the feature gates are sometimes projects, not groups or
users. For example for git object pools:
https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5872
This commit allows for setting feature group gates based on projects, by its
path as that seems most convenient.
Modifies authorize! method to accept a third param, and then use it in
combination with 'add_cluster' policy to appropriately restrict adding
multiple clusters
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/56110
`project.latest_successful_builds_for(ref)` is being used to find a
single job all the time. This results into us having to call `find_by`
inside of the controller which violates our CodeReuse/ActiveRecord
rubocop rule.
Refactor `project.latest_successful_builds_for(ref)` to
`project.latest_successful_build_for(job_name, ref)` which will execute
the `find_by` inside of the model.
Also create `project.latest_successful_build_for!(job_name, ref)` which
raises an exception instead of returning nil.
As mentioned in
https://gitlab.com/gitlab-org/gitlab-ee/issues/9035#note_129093444,
Rails 5 switched ActionDispatch::Request so that it no longer inherits
Rack::Request directly. A middleware that uses Rack::Request to
read the environment may see stale request parameters if
another middleware modifies the environment via ActionDispatch::Request.
To be safe, we should be using ActionDispatch::Request everywhere.
Adds the following initial CRUD endpoints for Clusters API:
- GET list of clusters
- GET specific cluster
- POST add existing cluster (mimic of "Add cluster")
- PUT update cluser
- DELETE destroy cluster
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/40473
Rémy Coutable
Kamil Trzciński
Grzegorz Bizon
Robert Schilling
Grzegorz Bizon
Kamil Trzciński
Lin Jen-Shin
Steve Azzopardi
Nick Thomas
Filipa Lacerda
Sam Bigelow
Douwe Maan
Robert Schilling
Stan Hu
Ben
Alejandro Rodríguez
Mathieu Parent
Zeger-Jan van de Weg
Shinya Maeda
Mayra Cabrera
Francisco Javier López
Robert Speicher
Heinrich Lee Yu