Расширение Pypi репозитория артефактов с помощью плагинов - PullRequest
Новая
       29

Расширение Pypi репозитория артефактов с помощью плагинов

0 голосов
/ 31 мая 2018

Я пытаюсь перенести устаревшую систему на использование артефакта.Однако у меня есть два блокировщика:

  1. старые скрипты требуют PyPixmlrpc, который в артефакте не поддерживает
  2. , они также используют upload_docs, не поддерживаемые реализацией pypi артефакта, либо
  3. меньшая проблема, старые скрипты вызывают регистр, и они ожидают 200 вместо 204 http кода статуса.

Могу ли я написать плагин для реализации этого?

Глядя на https://www.jfrog.com/confluence/display/RTF/User+Plugins Мне не удалось найти обратный вызов, когда запрашивается POST /api/pypi/<index-name>.

Если я смогу заставить

  1. работать на методы, которые мы на самом деле используем,
  2. просто притвориться развернутыми документами и
  3. ответить правильным кодом состояния
Я будудостаточно счастлив.

1 Ответ

0 голосов
/ 29 июня 2018

Как вы говорите, для конечных точек API-интерфейса Pypi отсутствует подключаемый модуль.Можно было бы использовать конечную точку altResponse для настройки загрузки артефактов, но тогда вы будете ограничены GET запросами без тела запроса, что также не является хорошим вариантом для вас.

Я думаюнаиболее жизнеспособным подходом было бы определение пользовательской конечной точки executions.При этом вы можете указать приемлемый метод, прочитать тело и установить свой собственный код ответа и тело.Основным недостатком этого является то, что вы не можете настроить путь (это всегда /api/plugins/execute/[execution_name]), но это можно обойти.

Конечные точки выполнения могут принимать параметры в следующей форме:

/api/plugins/execute/[execution_name]?params=[param_name]=[param_val]

Скажем, ваш плагин принимает параметр path, представляющий путь API, который будут вызывать ваши старые скрипты.Затем вы можете установить базовый URL-адрес на /api/plugins/execute/[execution_name]?params=path=/, чтобы путь API добавлялся к параметру.Кроме того, вы можете использовать nginx или другой обратный прокси-сервер, чтобы переписать исходный путь API к этой форме.

(Поскольку вы будете использовать XML-RPC, я не думаю, что вам придется беспокоиться о каких-либоэтого пути, но я все равно включаю его для полноты.)

Некоторые проблемы с этим подходом:

  • Конечные точки выполнения допускают только ответы String, поэтому отправка двоичных данныхв теле ответа может быть привередливее.Однако для тела запроса такого ограничения не существует.
  • Если вам требуется более одного метода запроса, вам потребуется более одной конечной точки выполнения.Это означает, что вам нужно будет использовать обратный прокси для перезаписи каждого метода в отдельную конечную точку.Опять же, поскольку XML-RPC просто использует POST, это, вероятно, не будет проблемой для вас.
  • Конечные точки выполнения не могут настраивать заголовки ответа.Поэтому, если ваши сценарии ожидают определенного Content-Type или другого заголовка, вам нужно будет использовать обратный прокси-сервер, чтобы вставить его в ответ.
...