djspiewak / sbt-github-packages

A simple sbt plugin for publishing to GitHub Packages, in the style of sbt-sonatype and sbt-bintray
Apache License 2.0
175 stars 27 forks source link

JVM Property alternative for credentials #24

Open dcsobral opened 4 years ago

dcsobral commented 4 years ago

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 commented 4 years ago

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

SalmonKing72 commented 4 years ago

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

andrewresearch commented 4 years ago

That workaround is not working for me.

SalmonKing72 commented 4 years ago

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 commented 4 years ago

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

chenrui333 commented 3 years ago

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 commented 3 years ago

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

Build Tools > sbt > sbt projects

image

This worked for me in Community Edition version 2020.3.

amitds1997 commented 3 years ago

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

Build Tools > sbt > sbt projects

image

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.