Большие Azure DevOps (и Azure DevOps Server 2019) наборы изменений завершаются неудачно с «Запросом слишком большой объект» - PullRequest
0 голосов
/ 08 января 2020

Кажется, что мы достигли предела при попытке добавить большой двоичный файл в Azure DevOps с использованием API REST. Такая же регистрация файлов работает нормально с использованием старых SOAP API, а также с использованием TFV C CLI (tf.exe). Но у нас есть случай, когда нам нужно время от времени проверять большие файлы программно с машин, на которых не установлена ​​VS. Мы пытаемся перенести наше приложение из старых SOAP API в REST API, потому что мы переходим на. NET Ядро, где SOAP API не поддерживается.

POST к API-интерфейс / _apis / tfvc / changesets (Create Changeset) с большими (> около 19 МБ) файлами приводит к:

HTTP 400: неправильный запрос

Эта проблема была зарегистрирована несколько раз на Azure DevOps. NET Образцы репозитория github, но это не тот форум, на который можно ответить на этот вопрос, поэтому на него не было ответа.

Как создать большие файлы в TFV C с использованием REST API?

Обновление 2020-01-13

Вот пример консольного приложения, которое мы использовали для демонстрации проблемы:

using Microsoft.TeamFoundation.SourceControl.WebApi;
using Microsoft.VisualStudio.Services.Common;
using Microsoft.VisualStudio.Services.WebApi;
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp1
{
    internal class Program
    {
        internal static async Task Main(string[] args)
        {
            var orgUrl = new Uri(args[0]);
            string serverPath = args[1];
            string localPath = args[2];
            string contentType = args[3];
            string pat = args[4];

            var changes = new List<TfvcChange>()
            {
                new TfvcChange()
                {
                    ChangeType = VersionControlChangeType.Add,
                    Item = new TfvcItem()
                    {
                        Path = serverPath,
                        ContentMetadata = new FileContentMetadata()
                        {
                            Encoding = Encoding.UTF8.WindowsCodePage,
                            ContentType = contentType,
                        }
                    },
                    NewContent = new ItemContent()
                    {
                        Content = Convert.ToBase64String(File.ReadAllBytes(localPath)),
                        ContentType = ItemContentType.Base64Encoded
                    }
                }
            };
            var changeset = new TfvcChangeset()
            {
                Changes = changes,
                Comment = $"Added {serverPath} from {localPath}"
            };

            var connection = new VssConnection(orgUrl, new VssBasicCredential(string.Empty, pat));
            var tfvcClient = connection.GetClient<TfvcHttpClient>();
            await tfvcClient.CreateChangesetAsync(changeset);
        }
    }
}

Запуск этого консольного приложения с zip-файлом ~ 50 МБ против Azure DevOps TFV C хранилище приводит к VssServiceResponseException (с внутренним ArgumentException) с сообщением: Максимальный размер запроса 26214400 байт был превышен Дед .

Обновление 2020-01-14

  • Добавлено отображение размера файла и длины содержимого base64 перед отправкой запроса TFV C в моем образец кода.
  • Исправлены мои наблюдения по поводу ограничения размера файла.
  • Исправлен код ошибки, возвращаемый Azure DevOps (400, а не 413).

Изначально я утверждал, что ограничение было около 13 МБ. Это было связано с ошибками, которые я видел с файлами> 20 МБ, успехом с файлами <около 10 МБ и ограничениями, описанными в связанных проблемах github. </p>

Я провел больше собственных тестов и сузил до 19 200 КБ в качестве фактического лимита. Это кажется правильным на основании сообщения об ошибке, указывающего ограничение в 26 214 400 байт. Файл в кодировке 19 МБ base-64 расширится примерно до 26 МБ.

Я также заметил, что в моих самых последних тестах при мониторинге с помощью Fiddler Azure DevOps возвращает код состояния 400 (не 413). В моих записях указывалось, что в какой-то момент в прошлом наблюдался слишком большой объект запроса 413. Возможно, это с более старой версией Azure DevOps Server? В любом случае, ошибка, которую мы видим сейчас, составляет 400 Bad Request.

Вот что Fiddler показывает для заголовков запроса:

POST /<...REMOVED...>/_apis/tfvc/changesets HTTP/1.1
Host: dev.azure.com
Accept: application/json; api-version=5.1
User-Agent: VSServices/16.153.29226.1 (NetStandard; Microsoft Windows 10.0.18363)
X-VSS-E2EID: 6444f0b5-57e0-45da-bd86-a4c62d8a1794
Accept-Language: en-US
X-TFS-FedAuthRedirect: Suppress
X-TFS-Session: 9f8e8272-db48-4e93-b9b0-717937244aff
Expect: 100-continue
Authorization: Basic <...REMOVED...>
Accept-Encoding: gzip
Content-Type: application/json; charset=utf-8; api-version=5.1
Content-Length: 26324162

И необработанный ответ:

HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 206
Content-Type: application/json; charset=utf-8
Expires: -1
P3P: CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
X-TFS-ProcessId: 7611d69f-e722-4108-8050-e55a61b1cbb4
Strict-Transport-Security: max-age=31536000; includeSubDomains
ActivityId: 15e046e5-3788-4fdb-896a-7d0482121ddd
X-TFS-Session: 9f8e8272-db48-4e93-b9b0-717937244aff
X-VSS-E2EID: 6444f0b5-57e0-45da-bd86-a4c62d8a1794
X-VSS-UserData: <...REMOVED...>
X-FRAME-OPTIONS: SAMEORIGIN
Request-Context: appId=cid-v1:e3d45cd2-3b08-46bc-b297-cda72fdc1dc1
Access-Control-Expose-Headers: Request-Context
X-Content-Type-Options: nosniff
X-MSEdge-Ref: Ref A: 7E9E95F5497946AC87D75EF3AAD06676 Ref B: CHGEDGE1521 Ref C: 2020-01-14T14:01:59Z
Date: Tue, 14 Jan 2020 14:02:00 GMT

{"$id":"1","innerException":null,"message":"The maximum request size of 26214400 bytes was exceeded.","typeName":"System.ArgumentException, mscorlib","typeKey":"ArgumentException","errorCode":0,"eventId":0}

1 Ответ

0 голосов
/ 09 января 2020

До настоящего времени наиболее полезным решением было выделить достаточно большой буфер посредством изменения конфигурации в IIS.

Go machine -> открыть диспетчер IIS:

enter image description here


(1) Выберите сайт вашей коллекции

(2) Дважды щелкните «Редактор конфигурации»

enter image description here

(3) Вставьте system.webServer/serverRuntime в раздел

(4) Разверните значение uploadReadAheadSize в соответствии с вашим сценарием.

Затем нажмите Apply, чтобы применить вышеуказанные изменения.


Я знаю, это будет очень дорого для больших тел запросов. Но, как я знаю, это часто используемый нами метод.

enter image description here

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...