Sbt-github-packages: Альтернатива свойства JVM для учетных данных

Рад принять PR для TokenSource , который делает это!

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

• Создайте личный токен доступа со всеми областями действия пакета, которые могут вам понадобиться (чтение, запись, удаление).
• в ~/.gitconfig... установите атрибут токена, как описано в файле README репо.
• В вашем файле build.sbt... githubTokenSource := TokenSource.GitConfig("github.token") || TokenSource.Environment("GITHUB_TOKEN")
• Оболочка IntelliJ + sbt должна работать успешно, не жалуясь на отсутствующую переменную среды.

Этот обходной путь не работает для меня.

Этот обходной путь не работает для меня.

Установлены ли для используемого вами токена личного доступа области пакетов? В файле ~/.gitconfig должна быть такая строка.

[github]
    token = <github_token_value>

Да, и это то, что у меня есть в файле .gitconfig.

Этот обходной путь не работает для меня.

Установлены ли для используемого вами токена личного доступа области пакетов? В файле ~/.gitconfig должна быть такая строка.

[github]
  token = <github_token_value>

Пробовал аналогичный ~/.gitconfig , тоже не в мою пользу.

Чтобы переменная среды работала в IntelliJ, включите оболочку sbt для перезагрузки проекта.

Инструменты сборки > sbt > проекты sbt

У меня это работало в Community Edition версии 2020.3.

Чтобы переменная среды работала в IntelliJ, включите оболочку sbt для перезагрузки проекта.

Инструменты сборки > sbt > проекты sbt

У меня это работало в Community Edition версии 2020.3.

Это не сработало для меня. Я настроил его через переменную окружения. Я обошел это, как обходной путь, используя плагин sbt-dotenv . После этого все заработало без каких-либо изменений в конфигурации IntelliJ или иным образом.

Вариант обходного пути, предложенный в этом выпуске , работал для моей установки IntelliJ.

githubTokenSource := TokenSource.Or(
  TokenSource.Environment("GITHUB_TOKEN"), // Injected during a github workflow for publishing
  TokenSource.GitConfig("github.token") // local token set in ~/.gitconfig
)

Я разделяю, что наша команда думала, что мы решили эту проблему с однопроектными и многопроектными сборками, внедрив значение githubTokenSource в качестве общего параметра в блок конфигурации каждого проекта в build.sbt. Все прошло хорошо для пользователей, IDE и рабочих пространств GitHub Action, у которых либо была запись ~/.gitconfig github.token, либо переменная env GITHUB_TOKEN.

Пока один из нас не решил использовать задачу runAll плагина Lagom.

Это немедленно умирает для исходной проблемы.

В разветвленном контексте, используемом плагином Lagom для развертывания сервисного роя, отсутствуют как переменная среды, так и файл ~/.gitconfig.

Мы изучаем способы установки среды для этой разветвленной среды выполнения.

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

Гуру СБТ.

Есть ли правильный способ «внедрить» параметр (особенно githubTokenSource ) в глобальное пространство имен, чтобы такой плагин, как sbt-github-packages , видел этот параметр для всех явно определенных проектов, для всех динамически определенных проектов ( как плагин Lagom), для всех фаз сборки и для всех разветвленных контекстов?

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

Возможно, это не вина этого конкретного плагина, но этот плагин обвиняют в том, что ему приходится делать всю эту внутреннюю операцию SBT, чтобы попытаться охватить все случаи.