Artifactory Установка NuGet не получает последнюю версию пакета

Question

У меня возникла проблема при установке пакетов NuGet из самодельного Artifactory. Когда идентификатор пакета получает более тридцати уникальных версий, команда установки NuGet становится неспособной идентифицировать последнюю версию. Изучая журнал из команды установки NuGet, я вижу, что он делает два веб-запроса.

GET https://artifactory.local/artifactory/api/nuget/<repository>/FindPackagesById()?id='<package ID>' 
OK https://artifactory.local/artifactory/api/nuget/<repository>/FindPackagesById()?id='<package ID>' 815ms 
GET https://artifactory.local/artifactory/api/nuget/<repository>/FindPackagesById()?$skip=80&id='<package ID>' 
OK https://artifactory.local/artifactory/api/nuget/<repository>/FindPackagesById()?$skip=80&id='<package ID>' 209 ms 

Когда я запускаю эти команды, я получаю ответ XML-фида с тридцатью и нулевыми записями соответственно. Если я отрегулирую параметр $ skip во втором запросе до тридцати, я увижу самые последние пакеты.

Неправильно ли Artifactory внедряет метод FindPackagesById API NuGet, не возвращая восемьдесят записей?

функции

• Artifactory версия 4.12.01
• командной строки NuGet версия 3.4.4.1321

Answer 1

Текущая реализация с локальными и виртуальных хранилищ NuGet мандатов макс 80 результатов на странице. Первый ответ файла OData (для первого запроса, который не имеет параметра $ skip в нем) должен иметь возможность возвращать 80 записей, при условии, что существует не менее 80 версий пакета.

Проблема, которую в настоящее время имеет компания Artifactory, и о которой мы знаем, происходит, когда один пакет (тот же идентификатор пакета) содержится в нескольких разных хранилищах и когда запрос отправляется через виртуальный репозиторий, который объединяет эти репозитории. Если в одном пакете имеется более 80 версий, Artifactory возвращает ссылку для разбивки на страницы с $ skip = 80 на первый ответ. Проблема заключается в том, что Artifactory (ошибочно) предполагает, что определенный идентификатор пакета будет существовать только в одном репозитории под виртуальным репо и, следовательно, отправляет $ skip = n ко всем агрегированным репозиториям один за другим, поэтому skip = 1 фактически пропускает два объекта, skip = 2 фактически пропускает 4, а skip = n по существу становится skip = 2n. Эта ошибка сообщается здесь и будет исправлена ​​в ближайшие месяцы:

https://www.jfrog.com/jira/browse/RTFACT-12379

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

До тех пор, пока RTFACT-12379 не будет исправлен, текущие (не столь идеальные) обходные пути для этого либо не используют виртуальный репозиторий для установки пакетов с более чем 80 версиями, либо для обеспечения того, чтобы определенный пакет больше не существовал чем один репозиторий.