Open dac09 opened 2 years ago
@dac09 I just want to make sure you confirmed this behavior on your setup. For me, I'm not sure if the conflict was due to what you describe here or that my local deploys were trying to use Env Var values from the Serverless Dashboard even though I wasn't able to deploy via the CI/CD service.
I resolve my problem by 1) adding Env Vars to the Serverless dashboard apps and 2) using the param
syntax in my yaml.
Note: I thought this setup would work in my favor as I'm now creating a GitHub workflow to deploy — not having to manage env var in GitHub would be great, right?!? But the deploy serverless
is failing 'cause it can't find the env vars... 🤦♂️
Yes @thedavidprice I did confirm this behaviour! I just used your project, but removed the org/app, and since I didn't have your local .serverless
cached files or .env.production
I think was a legit repro 👍
Confirming this is still a problem, which is exacerbated because we instruct users to create .env.production
in the Serverless Deploy Docs. Based on the docs, it's expected 1) you should continue to use .env.production and 2) redwood supports .env.context file naming. It does not.
See also https://github.com/redwoodjs/redwood/issues/5785 for an example of the confusion this creates.
We need to determine if we want to support this behavior. At this time, it's a low priority. If someone wants to take it on, we could support the effort.
A a minimum, we can update the Serverless Deploy docs and remove the .env.production
instructions.
cc @jtoar @Josh-Walker-GM
Hello, I'd love to progress on this, Pls assign it to me.
Say you have a
.env.defaults
withDATABASE_URL
definedAnd after running
yarn rw deploy sls --first-run
, and adding your DATABASE_URL varyour.env.production
looks like this:The deploys graphql lambda will use the DB defined in the defaults file.
Expected behaviour
Env vars should be loaded like:
.env.defaults -> .env -> .env.production, each one overriding anything with the same name