Wondering how to set up secret_key
# help
f
I'm using shuttle-secrets to provide SMTP config for a server that sends auth/verification emails. Currently I'm having trouble accessing the secrets data in a deployment, as I get an error saying that 'secret_key' isn't set. I can't find any documentation for this, nor find it in the shuttle.rs GitHub. Would love some help and maybe some updated documentation! Thanks!
e
Secrets are injected into the function with the
#[shuttle_runtime::main]
attribute like this:
Copy code
rs
#[shuttle_runtime::main]
async fn main(
    #[shuttle_secrets::Secrets] secret_store: SecretStore,
)
From there you can use the
get()
function on the secret_store to retrieve a secret by its name
f
While true, this doesn't answer my question. I've been looking into it more and the secret_key is actually configuration for Rocket, not a requirement of Shuttle secrets (as I thought previously). Normally secret_key is set via the Rocket.toml (which I have now done). This appears to run fine locally but it seems that shuttle.rs doesn't upload anything other than the src/**/*.rs files and the cargo.toml. This is one of a few problems I have with shuttle secrets (as it doesn't replace a real way to set Env variables for build time config). I'd love help from a shuttle developer who knows more but I appreciate anyone's help. I'm thinking about finding a less opinionated server system so that I can just run normal cargo commands (e.g. use a build.rs file, use a .env file, use Rocket.toml etc)
g
Gitignored files are not uploaded when deployed, Secrets.toml is the only way of getting around that. Setting env variables at build time is not officially supported. Setting them at the start of run time works though: In the
shuttle_runtime::main
function, you can extract secrets from the Secretstore, and use
std::env::set_var
. This has worked for me for loading AWS credentials into my program.
f
Oh gosh, I guess I'll just drop those lines from my gitignore then when I'm deploying. Secrets needed at build time are pretty common...
Also, the schema.sql and template files aren't in my gitignore, so I'm not sure your theory matches all of my experience
g
After checking the code, these are the rules for the files: -
ignore::walk::WalkBuilder
is used, which excludes files listed in files such as .gitignore and .ignore - target/ is always ignored - hidden files are always ignored
f
Hmm, it would be really good if files listed in cargo.toml's include were always included. No idea why Rocket.toml seems to be ignored in my project (I'm trying various different settings and setups to fix it). So far I've tried [global] [production] [release] and [prod]. Build.rs doesn't seem to be respected either (I'm not getting any logs from my build.rs file) No idea about the html templates or schema.sql Updated to latest shuttle, still nothing...
Oh wait. Uninstalled and reinstalled shuttle and I have picked up a different version this time.
g
The logs are not 100% trustworthy. The build script does get run though.
g
Hey Jay! How's it looking so far?
f
Updated everything and still had those same issues. Switched to a different service render.com and it just ...uploaded everything and supported environment variables. Sorry. Not trying to be rude or ungrateful about it, but it was so much simpler...
a
No worries, thank you for letting us know this is an issue (re compatibility issues with rocket.toml files). Shuttle is still currently in open alpha at the moment so of course there are issues to be expected - any useful feedback is encouraged
g
I agree that env variables at build time is a desired feature. I've always wondered why Shuttle uses its own Secrets.toml file instead of a .env file approach.
f
Worth looking into the non '.rs' files too. I think the files weren't available at build time, perhaps shuttle would have made them accessible later?
s
Hmm, non
.rs
files should work. Else static folders would break 🤔 We do move the binary after compiling it though. So maybe Rocket was just looking for it in the wrong place