- 26 5月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 15 4月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 06 4月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 01 4月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 27 3月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 23 3月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 19 3月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 14 3月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 03 3月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 25 2月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 19 2月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 11 2月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 31 1月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 10 1月, 2020 1 次提交
-
-
由 GitLab Bot 提交于
-
- 20 12月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 10 12月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 25 11月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
-
- 11 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 02 10月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 25 9月, 2019 1 次提交
-
-
由 GitLab Bot 提交于
-
- 01 9月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
-
- 29 8月, 2019 1 次提交
-
-
由 Jacob Vosmaer 提交于
-
- 23 8月, 2019 1 次提交
-
-
由 Jan Provaznik 提交于
-
- 10 8月, 2019 1 次提交
-
-
由 Stan Hu 提交于
This sanitizes some log messages to be consistent with CE. Full list of changes: https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/CHANGELOG
-
- 25 4月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
-
- 11 4月, 2019 1 次提交
-
-
由 Francisco Javier López 提交于
-
- 10 4月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
-
- 05 4月, 2019 1 次提交
-
-
由 Francisco Javier López 提交于
We're moving from using terminology related to terminals when we refer to Websockets connections in Workhorse. It's more appropiate a concept like channel.
-
- 02 4月, 2019 3 次提交
-
-
由 Patrick Bajao 提交于
-
由 Patrick Bajao 提交于
Add `GetArchiveRequest` to git-archive params. Modifies `Git::Repository#archive_metadata` to append `path` to `ArchivePrefix` so it'll not hit the cache of repository archive when it already exists.
-
由 Jan Provaznik 提交于
Adds a rake task which can be used for removing EXIF data from existing uploads.
-
- 13 2月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
-
- 06 2月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
-
- 04 2月, 2019 1 次提交
-
-
由 Nick Thomas 提交于
-
- 31 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.
-
- 23 1月, 2019 2 次提交
-
-
由 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.
-
由 Andrew Newdigate 提交于
-
- 12 12月, 2018 1 次提交
-
-
由 Nick Thomas 提交于
-
- 11 12月, 2018 1 次提交
-
-
由 Andrew Newdigate 提交于
-
- 07 12月, 2018 1 次提交
-
-
由 Francisco Javier López 提交于
-