Получение ошибки HTTP 400 при попытке очистить кеш виртуального репозитория Helm в Jfrog Artifactory через API
У меня проблема с кешем виртуального репозитория Helm (содержащего только локальное репо) на собственной JFrog Artifactory (версия 7.49.8). Я пытался очистить кеш всего репо через API https://jfrog.com/help/r/jfrog-rest-apis/zap-cache.
Тем не менее, я продолжаю получать ошибки статуса 400, независимо от того, пробую ли я виртуальное или репо или локальное репо (как следует из сообщения об ошибке):
curl -H "X-Jfrog-Art-Api: $ADMIN_API_KEY" \
http://artifactory.my-company.com/artifactory/api/zap/my-virtual-helm-repo
{
"errors": [
{
"status": 400,
"message": "Repository 'my-virtual-helm-repo' is not a local repository"
}
]
}
Итак, я попытался отключить локальное репо, включенное в виртуальное репо (хотя пользовательский интерфейс не предлагает удаление локальных репозиториев):
curl -H "X-Jfrog-Art-Api: $ADMIN_API_KEY" \
http://artifactory.my-company.com/artifactory/api/zap/my-included-local-helm-repo
{
"errors": [
{
"status": 400,
"message": "Got a zap request on a non-local-cache node 'my-included-local-helm-repo:'."
}
]
}
Я могу Zap Cache виртуального репозитория через пользовательский интерфейс Artifactory. Как заставить работать вызов REST?
Ответы 2
Разобьем этот ответ на две части:
Часть 1. Что служит Zap-кэшу?
Удаление кэша означает принудительное истечение времени ожидания периода кэширования извлечения и пропущенного периода кэширования извлечения. Вы также можете удалить весь кеш репозитория. Эта информация получена из документации JFrog. Другими словами, функция Zap Cache сбрасывает MCRP для всего кэшированного репозитория, гарантируя, что свежие метаданные отправляются клиенту после Zap.Ссылка на Zap Cache
Пользователям, которым нужны точные и актуальные метаданные, следует понизить значение параметра, потенциально отключив его, установив значение «0». Это действие приведет к более медленному извлечению данных, поскольку Artifactory будет часто предоставлять свежие метаданные. Однако это гарантирует, что всегда используются наиболее точные данные. Если пользователи отдают приоритет производительности, им следует увеличить этот параметр. Тем не менее, это означает, что Artifactory будет чаще использовать свой кеш, что ставит под угрозу точность. Обратитесь к «Как работает удаленный репозиторий», чтобы лучше понять.
Часть 2 - Понимание причины отказа
После понимания термина и его значения важно отметить, что кеширование zapping в виртуальном репозитории отличается от кеша zapping из удаленного репозитория (конечная точка API отличается).
Для запуска API кэша zap в удаленном репозитории это точно так, как вы упомянули выше. интересно почитать о том, как работают удаленные репозитории
Для запуска zap-кэша в виртуальном репозитории:
curl -H "X-Jfrog-Art-Api: $ADMIN_API_KEY" 'http://artifactory.my-company.com/artifactory/api/artifactactions/zapVirtual' -H 'Content-Type: application/json' -H 'Accept: application/json, text/plain' --data-raw '{"repoKey":"npm-virtual","path":""}'
{"info":"The caches of 'def-npm' have been successfully zapped."}
Я попытался добавить удаленный репозиторий в виртуальный репозиторий и запустить указанный API-интерфейс zap cache. он дал тот же ответ. Я немного расследую и вернусь к вам со своими выводами. Спасибо, что подняли это!
После дополнительного исследования я могу подтвердить, что запрос кэширования в виртуальном репозитории должен выглядеть следующим образом: curl -H "X-Jfrog-Art-Api: $ADMIN_API_KEY" 'Artifactory.my-company.com/artifactory/api/ Artifactactions/…' -H 'Тип содержимого: application/json' -H 'Принять: application/json, text/plain' --data-raw '{"repoKey":"def-npm","path ":""}' Я продолжу и обновлю ответ.
Я сам видел соответствующий вызов UI-API в Browser DevTools. Поскольку он не был задокументирован, его использование опасно. Но я предполагаю, что мне придется жить опасно, пока Jfrog не разберется с этим. Это временное решение. Спасибо, что разобрались с API без пользовательского интерфейса и за то, что API-ключ работает с ним.
Чтобы решить эту проблему, вы можете попробовать устранить неполадки, проверив, есть ли какие-либо ошибки в URL-адресе запроса API или полезной нагрузке, убедившись, что у вас есть достаточные разрешения для выполнения действия, и убедитесь, что нет временных проблем с серверами или сетью Jfrog Artifactory.
Спасибо за подведение итогов. Однако мой виртуальный репозиторий не содержит удаленного репозитория. Я пытался найти в документах и блогах Jfrog четкое заявление о том, предназначен ли Cache Zapping только для удаленных репозиториев, но все, что я нашел, это то, что он может решить проблемы с удаленными репозиториями (ваша вторая ссылка). Но ничего об этом не было специально для удаленных репозиториев. И в конце концов, Arti позволяет мне загружать кэши виртуальных репозиториев в веб-интерфейсе. Поэтому, если пользовательский интерфейс не должен позволять мне загружать кеш виртуального репо, я не ожидаю, что REST API будет более ограничивающим.