-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serverless deploy does not pick up env vars from .env.production, when also defined in .env.defaults #4548
Comments
@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 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 |
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 |
UpdateConfirming this is still a problem, which is exacerbated because we instruct users to create See also #5785 for an example of the confusion this creates. Next StepsWe 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. Update DocumentationA a minimum, we can update the Serverless Deploy docs and remove the |
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
The text was updated successfully, but these errors were encountered: