how to add secret env variable needed for sbt resolve when starting vscode as macos app…?

[hedefalk]

I'm using a private github repo and need token on env to resolve:

val githubTokenSourceSetting =
githubTokenSource := TokenSource.Environment("GITHUB_TOKEN")

I typically just do:

 export GITHUB_TOKEN=$(pass github/my_repo_token)

in my build startup. However, I start vscode as a macos app, not inheriting any env from my shell's and therefore I don't have those variables. What's the best way to resolve this?

[tgodzik]

Thanks for asking! There is a number of possible workarounds:

• you should be able to start Visual Studio Code from the shell using the code command inside the workspace
• you can run the build import via a custom script (you can add the path to it in the settings) that will setup the environment, something like this:

export GITHUB_TOKEN=$(pass github/my_repo_token)
sbt "$@"

• you can run the import manually sbt -Dbloop.export-jar-classifiers=sources bloopInstall

[hedefalk]

Thanks!

The weird thing is that I have had this setup for some time and the error just came up today in vscode. Starting vscode from cli is not a viable solutions for me, but I am running an sbt on the side.

I tried something like point 2 there in metals.sbtScript setting, but couldn't get it to work. env dependencies just turned out too be too much for me. First I tried to create an inline script but couldn't get that working so better with a file like you suggested. I did:

#!/usr/local/bin/bash
export GITHUB_TOKEN=$(pass github/my_repo_token)
sbt "$@"

and I think it works if GPG has cached the passphrase. I experimented with GPG_TTY too but I'm not sure how that stuff will work inside vscode. I even tried setting manual tty like export GPG_TTY=/dev/ttys003 which then triggered pin-entry in my terminal emulator (kitty) and all hell broke loose.

If I try that script without having a pretty fresh call already to pass on the side I get:

2021.01.21 18:24:34 INFO  running '/Users/viktor/dev/fcg/Oasys-backend/sbt.sh -Dbloop.export-jar-classifiers=sources bloopInstall'
2021.01.21 18:24:39 ERROR gpg: decryption failed: No secret key

Anyways, I cleared all my metals customizations in vscode and killed all dangling bloop processes, made sure I had a running sbt on the side and then everything started fine the next time I restarted the vscode workspace. I guess I had made a bloopInstall on this side sbt then so that would be your third suggestion?

This was all triggered using "metals: import build". Now I can do this over and over again without any metals settings in vscode without it doing that resolution within vscode again.

But am I understanding it right that if I do bloopInstall on the side, the metals start from within vscode wouldn't trigger that any more? That's definitely good enough for me. Just not sure why this happened over and over today while having an up-to-date sbt on the side…

[dos65]

@hedefalk
In addition to these workarounds that was provided by @tgodzik I think the less painful solution might be to add a file wiith secret value and use || combinator in build definition.

Smth like:

githubTokenSource := TokenSource.Environment("GITHUB_TOKEN") || TokenSource.GitConfig("$path_to_local_config")

[hedefalk]

I actually had that before but removed it in a security push of removing any clear text secrets :) Thanks though!

[hedefalk]

Follow-up question:

I'm really fine with option 3, using bloopInstall on my side sbt. I'm however wondering if I'm using the intended workflow when I need to sbt reload.

So say I do branch switch and need to reload my build definition. I then get a pop-up within vscode that the build definition changed. Should I ignore this and instead do sbt bloopInstall and in vscode do "metals: restart build server"?

[tgodzik]

With manual installation I would ignore the pop-up - you can ignore forever I think and then do:

• run sbt -Dbloop.export-jar-classifiers=sources bloopInstall
• run VS Code command Metals: Connect to build server - restart is not needed in that case.