Sbt-github-packages: Alternativa de propriedade JVM para credenciais

Feliz em aceitar um PR por um TokenSource que faz isso!

Concordo que isso seria útil, mas estou fazendo isso como uma solução rápida/suja, se você precisar.

• Crie um token de acesso pessoal com todos os escopos de pacote que você possa precisar (ler, gravar, excluir).
• em ~/.gitconfig... defina o atributo token conforme descrito no arquivo README do repositório.
• No seu arquivo build.sbt... githubTokenSource := TokenSource.GitConfig("github.token") || TokenSource.Environment("GITHUB_TOKEN")
• O shell IntelliJ + sbt deve ser bem-sucedido sem reclamar da variável de ambiente ausente.

Essa solução alternativa não está funcionando para mim.

Essa solução alternativa não está funcionando para mim.

O token de acesso pessoal que você usou tem os escopos de pacotes definidos? O arquivo ~/.gitconfig deve ter uma linha como esta.

[github]
    token = <github_token_value>

Sim, e é isso que tenho no arquivo .gitconfig.

Essa solução alternativa não está funcionando para mim.

O token de acesso pessoal que você usou tem os escopos de pacotes definidos? O arquivo ~/.gitconfig deve ter uma linha como esta.

[github]
  token = <github_token_value>

Eu tentei o similar ~/.gitconfig , também não funcionou a meu favor.

Para fazer a variável de ambiente funcionar no IntelliJ, habilite o shell sbt para recarregar o projeto.

Ferramentas de compilação > sbt > projetos sbt

Isso funcionou para mim na versão Community Edition 2020.3.

Para fazer a variável de ambiente funcionar no IntelliJ, habilite o shell sbt para recarregar o projeto.

Ferramentas de compilação > sbt > projetos sbt

Isso funcionou para mim na versão Community Edition 2020.3.

Isto não funcionou para mim. Eu configurei através da variável de ambiente. Eu contornei isso, como solução alternativa, usando o plugin sbt-dotenv . Depois disso, tudo funcionou sem nenhuma alteração na configuração do IntelliJ ou de outra forma.

Uma variação de uma solução alternativa sugerida neste problema funcionou para minha configuração do IntelliJ.

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

Compartilho que nossa equipe achou que tínhamos resolvido esse problema com compilações de projeto único e de vários projetos injetando o valor githubTokenSource como uma configuração comum no bloco de configuração de cada projeto no build.sbt. Tudo correu bem para usuários, IDEs e espaços de trabalho GitHub Action que tinham uma entrada ~/.gitconfig github.token ou uma variável env GITHUB_TOKEN.

Até que um de nós decidiu usar a tarefa runAll do plugin Lagom.

Isso morre imediatamente para o problema original.

O contexto bifurcado usado pelo plugin Lagom para implantar o enxame de serviço não possui a variável de ambiente e um arquivo ~/.gitconfig.

Estamos pesquisando maneiras de definir o ambiente para esse ambiente de execução bifurcada.

No entanto, a suposição geral de que um GITHUB_TOKEN deve ser fornecido mesmo que as tarefas do plug-in do pacote GitHub não estejam sendo chamadas está provando ser frustrante para nossos usuários e bots que ainda não têm esse token prontamente disponível.

gurus do SBT.

Existe uma maneira adequada de "injetar" uma configuração (especialmente githubTokenSource ) em um namespace global para que um plug-in como sbt-github-packages veja essa configuração para todos os projetos definidos explicitamente, para todos os projetos definidos dinamicamente ( como o plugin do Lagom cria), para todas as fases de construção e para todos os contextos bifurcados?

É oneroso ter que reivindicar explicitamente a localização de uma credencial que é invariável em todas essas permutações repetidamente, tendo que se aprofundar nos detalhes de como o SBT gerencia namespaces ou caches de estado.

Talvez isso não seja culpa desse plugin em particular, mas esse plugin é o culpado por ter que fazer toda essa cirurgia interna do SBT para tentar cobrir todos os casos.