JVM Property alternative for credentials

[dcsobral]

IntelliJ cannot load projects with this plugin because it offers no way of defining environment variables to be set for sbt when loading a project. Setting them for an app on MacOS seems to be unreliable, as previously working techniques were broken on OS updates.

It would be nice if the github token could be alternatively provided as a JVM property, which can be easily set.

[djspiewak]

Happy to accept a PR for a TokenSource which does this!

[SalmonKing72]

I agree this would be helpful, but I'm doing this as a quick/dirty solution if you need it.

• Create a personal access token with all of the package scopes you may need (read, write, delete).
• in ~/.gitconfig... set the token attribute as described in the repo README file.
• In your build.sbt file... githubTokenSource := TokenSource.GitConfig("github.token") || TokenSource.Environment("GITHUB_TOKEN")
• IntelliJ + sbt shell should succeed without complaining about the missing environment variable.

[andrewresearch]

That workaround is not working for me.

[SalmonKing72]

That workaround is not working for me.

Does the personal access token you used have the packages scopes set? The ~/.gitconfig file should have a line like this.

[github]
	token = <github_token_value>

[andrewresearch]

Yes, and that is what I have in the .gitconfig file.

[chenrui333]

That workaround is not working for me.

Does the personal access token you used have the packages scopes set? The ~/.gitconfig file should have a line like this.

[github]
	token = <github_token_value>

I have tried the similar ~/.gitconfig, it did not work out for my favor either.

[jchernan]

To make the environment variable work in IntelliJ, enable sbt shell for project reload.

Build Tools > sbt > sbt projects

This worked for me in Community Edition version 2020.3.

[amitds1997]

To make the environment variable work in IntelliJ, enable sbt shell for project reload.

Build Tools > sbt > sbt projects

This worked for me in Community Edition version 2020.3.

This did not work for me. I had it configured via the environment variable. I got around this, as a workaround, by using the sbt-dotenv plugin. After this, everything worked without any changes in the IntelliJ configuration or otherwise.

[tomrijntjes]

A variation of a workaround suggested in this issue worked for my IntelliJ setup.

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

[lonniev]

I share that our team thought we had this issue settled with single-project and with multi-project builds by injecting the githubTokenSource value as a common setting into each project's configuration block in the build.sbt. Everything went well for users, IDEs, and GitHub Action workspaces that either had a ~/.gitconfig github.token entry or had a GITHUB_TOKEN env variable.

Until one of us decided to use the Lagom plugin's runAll task.

This dies immediately for the original problem.

The forked context used by the Lagom plugin for deploying the service swarm lacks both the environment variable and a ~/.gitconfig file.

We are researching ways to set the environment for that forked execution environment.

However, the overall assumption that a GITHUB_TOKEN must be provided even if the GitHub Package plugin tasks are not being called up is proving to be frustrating for our users and bots that don't happen to already have that token readily available.

[lonniev]

SBT gurus.

Is there a proper way to "inject" a setting (especially githubTokenSource) into a global namespace so that a plugin like sbt-github-packages sees that setting for all explicitly defined projects, for all dynamically defined projects (like Lagom's plugin creates), for all build phases, and for all forked contexts?

It is onerous to have to explicitly claim the location of a credential which is invariant across all those permutations over and over, having to drill into the details of how SBT manages namespaces or state caches.

Perhaps this is not the fault of this particular plugin but this plugin is the one getting blamed for having to do all this internal SBT surgery to try to cover all cases.