- 14 2月, 2019 2 次提交
-
-
由 Lin Jen-Shin 提交于
And add tests
-
由 Robert Schilling 提交于
-
- 13 2月, 2019 2 次提交
-
-
由 Robert Schilling 提交于
-
由 Robert Schilling 提交于
-
- 07 2月, 2019 3 次提交
-
-
由 Jan Provaznik 提交于
Cached markdown version is composed both from global and local markdown version. This allows admins to bump version locally when needed (e.g. when external URL is changed).
-
由 GotenXiao 提交于
- 05 2月, 2019 2 次提交
-
-
由 Rubén Dávila 提交于
In order to have an accurate date about the last activity of a User we need to update the last_activity_on field when the User is visiting some basic pages of GitLab like pages related to Dashboards, Projects, Issues and Merge Requests
-
由 Stan Hu 提交于
Users downloading non-ASCII attachments would see garbled characters. When used with object storage, AWS S3 would return an InvalidArgument error: Header value cannot be represented using ISO-8859-1. Per RFC 5987 and RFC 6266, Content-Disposition should be encoded properly. This commit takes the Rails 6 implementation of ActiveSuppport::Http::ContentDisposition (https://github.com/rails/rails/pull/33829) and ports it here. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/47673
-
- 04 2月, 2019 1 次提交
-
-
由 Dylan MacKenzie 提交于
-
- 31 1月, 2019 9 次提交
-
-
由 Nick Thomas 提交于
LFS uploads are handled in concert by workhorse and rails. In normal use, workhorse: * Authorizes the request with rails (upload_authorize) * Handles the upload of the file to a tempfile - disk or object storage * Validates the file size and contents * Hands off to rails to complete the upload (upload_finalize) In `upload_finalize`, the LFS object is linked to the project. As LFS objects are deduplicated across all projects, it may already exist. If not, the temporary file is copied to the correct place, and will be used by all future LFS objects with the same OID. Workhorse uses the Content-Type of the request to decide to follow this routine, as the URLs are ambiguous. If the Content-Type is anything but "application/octet-stream", the request is proxied directly to rails, on the assumption that this is a normal file edit request. If it's an actual LFS request with a different content-type, however, it is routed to the Rails `upload_finalize` action, which treats it as an LFS upload just as it would a workhorse-modified request. The outcome is that users can upload LFS objects that don't match the declared size or OID. They can also create links to LFS objects they don't really own, allowing them to read the contents of files if they know just the size or OID. We can close this hole by requiring requests to `upload_finalize` to be sourced from Workhorse. The mechanism to do this already exists.
-
由 Grzegorz Bizon 提交于
-
由 Robert Schilling 提交于
-
由 Robert Schilling 提交于
-
由 Robert Schilling 提交于
-
由 Robert Schilling 提交于
-
由 Robert Schilling 提交于
-
由 Robert Schilling 提交于
-
由 Robert Schilling 提交于
-
- 30 1月, 2019 1 次提交
-
-
由 Shinya Maeda 提交于
It was leaings confidential issue titles and MR titles to any users Fix spec Fix spec Fix tests
-
- 25 1月, 2019 1 次提交
-
-
由 Kamil Trzciński 提交于
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.
-
- 24 1月, 2019 2 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Steve Azzopardi 提交于
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
-
- 23 1月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
LFS uploads are handled in concert by workhorse and rails. In normal use, workhorse: * Authorizes the request with rails (upload_authorize) * Handles the upload of the file to a tempfile - disk or object storage * Validates the file size and contents * Hands off to rails to complete the upload (upload_finalize) In `upload_finalize`, the LFS object is linked to the project. As LFS objects are deduplicated across all projects, it may already exist. If not, the temporary file is copied to the correct place, and will be used by all future LFS objects with the same OID. Workhorse uses the Content-Type of the request to decide to follow this routine, as the URLs are ambiguous. If the Content-Type is anything but "application/octet-stream", the request is proxied directly to rails, on the assumption that this is a normal file edit request. If it's an actual LFS request with a different content-type, however, it is routed to the Rails `upload_finalize` action, which treats it as an LFS upload just as it would a workhorse-modified request. The outcome is that users can upload LFS objects that don't match the declared size or OID. They can also create links to LFS objects they don't really own, allowing them to read the contents of files if they know just the size or OID. We can close this hole by requiring requests to `upload_finalize` to be sourced from Workhorse. The mechanism to do this already exists.
-
- 22 1月, 2019 3 次提交
-
-
由 Brett Walker 提交于
including refactoring, disabling sourcepos for pipelines that don't need it, and minimizing spec changes by disabling sourcepos when not testing for it explicitly.
-
由 Brett Walker 提交于
This adds 'data-sourcepos' to tags, indicating which line of markdown it came from. Sets the stage for intelligently manipulating specific lines of markdown.
-
由 Katrin Leinweber 提交于
-
- 21 1月, 2019 1 次提交
-
-
由 Robert Schilling 提交于
-
- 20 1月, 2019 1 次提交
-
-
由 Stan Hu 提交于
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
-
- 17 1月, 2019 3 次提交
-
-
由 Ben 提交于
-
由 Jasper Maes 提交于
-
由 Alejandro Rodríguez 提交于
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.
-
- 16 1月, 2019 3 次提交
-
-
由 Mathieu Parent 提交于
-
由 Robert Schilling 提交于
-
由 Robert Schilling 提交于
-
- 15 1月, 2019 2 次提交
-
-
由 Grzegorz Bizon 提交于
-
由 Robert Schilling 提交于
-
- 14 1月, 2019 2 次提交
-
-
由 Zeger-Jan van de Weg 提交于
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.
-
由 Hiroyuki Sato 提交于
-
- 11 1月, 2019 1 次提交
-
-
由 Shinya Maeda 提交于
We introduced releases_page feature flag. Given this feature is deemed stable, we should remove this flag before 19th.
-