Sbt-github-packages: Alternativa de propiedad JVM para credenciales

¡Feliz de aceptar un PR para un TokenSource que hace esto!

Estoy de acuerdo en que esto sería útil, pero lo estoy haciendo como una solución rápida/sucia si la necesita.

• Cree un token de acceso personal con todos los alcances del paquete que pueda necesitar (lectura, escritura, eliminación).
• en ~/.gitconfig... configure el atributo del token como se describe en el archivo README del repositorio.
• En su archivo build.sbt... githubTokenSource := TokenSource.GitConfig("github.token") || TokenSource.Environment("GITHUB_TOKEN")
• IntelliJ + sbt shell debería tener éxito sin quejarse de la variable de entorno que falta.

Esa solución no funciona para mí.

Esa solución no funciona para mí.

¿El token de acceso personal que usó tiene configurados los alcances de los paquetes? El archivo ~/.gitconfig debería tener una línea como esta.

[github]
    token = <github_token_value>

Sí, y eso es lo que tengo en el archivo .gitconfig.

Esa solución no funciona para mí.

¿El token de acceso personal que usó tiene configurados los alcances de los paquetes? El archivo ~/.gitconfig debería tener una línea como esta.

[github]
  token = <github_token_value>

Probé el ~/.gitconfig similar, tampoco funcionó a mi favor.

Para que la variable de entorno funcione en IntelliJ, habilite sbt shell para la recarga del proyecto.

Herramientas de compilación > sbt > proyectos sbt

Esto funcionó para mí en Community Edition versión 2020.3.

Para que la variable de entorno funcione en IntelliJ, habilite sbt shell para la recarga del proyecto.

Herramientas de compilación > sbt > proyectos sbt

Esto funcionó para mí en Community Edition versión 2020.3.

Esto no funcionó para mí. Lo tenía configurado a través de la variable de entorno. Solucioné esto, como una solución alternativa, usando el complemento sbt-dotenv . Después de esto, todo funcionó sin cambios en la configuración de IntelliJ o de otra manera.

Una variación de una solución sugerida en este problema funcionó para mi configuración de IntelliJ.

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

Comparto que nuestro equipo pensó que habíamos resuelto este problema con compilaciones de un solo proyecto y de varios proyectos al inyectar el valor de githubTokenSource como una configuración común en el bloque de configuración de cada proyecto en build.sbt. Todo salió bien para los usuarios, los IDE y los espacios de trabajo de GitHub Action que tenían una entrada ~/.gitconfig github.token o una variable de entorno GITHUB_TOKEN.

Hasta que uno de nosotros decidió usar la tarea runAll del complemento Lagom.

Esto muere inmediatamente por el problema original.

El contexto bifurcado utilizado por el complemento de Lagom para implementar el enjambre de servicios carece tanto de la variable de entorno como del archivo ~/.gitconfig.

Estamos investigando formas de configurar el entorno para ese entorno de ejecución bifurcado.

Sin embargo, la suposición general de que se debe proporcionar un GITHUB_TOKEN incluso si las tareas del complemento del paquete GitHub no se están llamando está demostrando ser frustrante para nuestros usuarios y bots que no tienen ese token disponible.

Gurús de SBT.

¿Existe una forma adecuada de "inyectar" una configuración (especialmente githubTokenSource ) en un espacio de nombres global para que un complemento como sbt-github-packages vea esa configuración para todos los proyectos definidos explícitamente, para todos los proyectos definidos dinámicamente ( como crea el complemento de Lagom), para todas las fases de compilación y para todos los contextos bifurcados?

Es oneroso tener que reclamar explícitamente la ubicación de una credencial que es invariable en todas esas permutaciones una y otra vez, y tener que profundizar en los detalles de cómo SBT administra los espacios de nombres o las cachés de estado.

Quizás esto no sea culpa de este complemento en particular, pero este complemento es el que está siendo culpado por tener que hacer toda esta cirugía SBT interna para tratar de cubrir todos los casos.