-
Notifications
You must be signed in to change notification settings - Fork 2.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
Spec out new env system #2613
Comments
Today, we received the feedback that I'd be great to set these right in the UI for a project. Basically, you can set every secret and add a dev AND/OR prod value for it. After that, For existing deployments (so that reverts work) we want to lock to the env that was available at that exact time. |
Glad to hear this is getting some attention. Could I also ask that "test" cases be considered. i.e. multiple env sets for a local machine |
I have been struggling for hours to get my environment variables working in the I think the docs are pretty confusing as it points out to different ways of exposing environment variables. The docs I have looked at:
Eventually I got it working like this:
{
"env": {
"TEST": "@test"
}
}
TEST="test-dev"
{
"env": {
"TEST": process.env.TEST
}
} anywhere on my functions => console.log(process.env.TEST); // "test-dev" That's for dev environment. For production you need to set Now's secrets executing:
Then you will see Note, works as well for Edit: never mind, I keep having conflicts and when logging |
This comment has been minimized.
This comment has been minimized.
@varna I guess you meant |
Yes, I meant |
@leo Looks good to me! Maybe it is possible to add "custom" environments, so I can setup a dev, staging and production environment as I wish ;) |
Thanks for the input, @ties-v! We'll involve this feedback in our upcoming discussions about refining the environment variable system. |
I am trying out the zero-config as well and I don't understand how to define ENV variables without attaching a now.json file. Did I overlook something? |
@dohomi There's currently no way to do that. You will have to add |
@leo thanks for the heads up - I thought I forgot something while reading the docs. One question: if I want a "as near as zero config" at the moment, I started to have an "api/[my-service-file.js]" structure. What would be an ideal |
I did not feel like retyping secrets this morning... I present you You can check it out as workflow idea. Dotenvs are easy, but secrets are must-have because of github CI/ sharing/ safety. Here I have something like the best of two worlds. Btw. It would be nice to allow some unsafe/dev secrets that can be read via API. Something safer than commiting .env to git, but shareable. |
|
Food for thought: I stumbled upon SecretHub which is a framework for secret management for all microservices in your stack, independently of the technology used. To use such system with Now, a integration system for secrets would be required. Maybe this is something that can be taken into consideration? |
At a minimum it would be useful to be able to pass an argument to My use case is that I have an API endpoint that I use in my app and want to be able to use As an example I would like to do the following. In
In
Then I could start my local now app with either |
My proposal is to force a convention which will cover most situations. Out of the box, NextJS should be reading some of these files, if present. This is especially convenient to use with Github integration. I use this convention myself in all my projects. In ascending order of precedence (from less important, to more important which will override previous), here it is:
|
Why not just use dotenv-flow?
… On Dec 26, 2019, at 2:51 PM, Jerry Green ***@***.***> wrote:
My proposal is to force a convention which will cover most situations. By default, NextJS should read some of these files, if present. In ascending order of precedence (from less important, to more important which will override previous). This is especially convenient to use with Github integration. I use this convention myself in all my projects. So here it is:
.env.default
This is full set of environment variables which are used by your NextJS app, with some default values (which often are empty strings; an example: SOME_MY_VAR= or equivalent SOME_MY_VAR='' or SOME_MY_VAR="", - in which case it doesn't set anything but it helps to indicate what's even possible to change with env vars). Always read by NextJS, if present. Should be committed into source version control.
.env.production
This is some environments related to remote (deployed) app. Read by NextJS only on deployed apps or when next start is used. Should be committed into source version control. Overrides values of the file above.
.env
This is custom settings for a concrete user. It's supposed to be in .gitignore and in many cases the file should be empty or even not exist. When debugging, though, you may override anything with this file. May have secret keys. Overrides values of the files above.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#2613>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABHHB6PY5OHK3HMZV5BAPTQ2UKLJANCNFSM4IGP3V6Q>.
|
@agrohs not every part of that flow has sense, especially for NextJS. Also, they state to store canonical |
In that case, all I can share is that the convention you proposed is overly opinionated IMHO
… On Dec 26, 2019, at 5:53 PM, Jerry Green ***@***.***> wrote:
@agrohs <https://github.com/agrohs> not every part of that flow has sense, especially for NextJS. Also, they state to store canonical .env in source control, which is absolutely weird for developers who by some reasons prefer a single .env file over all of this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2613>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABHHB4A2HXCF6KXKU7W22DQ2U7WNANCNFSM4IGP3V6Q>.
|
Thank you for creating this issue! Please note that – in order for us to be able to handle each feature request with care – we have to consume all of them through a unified pipeline that makes it easier for us to prioritize, track and progress on the features our user base is interested in. In turn, the Issues tab on this repository is best only be used for reporting bugs, which we can immediately act on. For well-explained feature requests (like the one you just posted), please contact us at support@zeit.co, so that we can consider adding it to our roadmap. In the case of your specific feature recommendation, you can rest assured that we're already tracking it on our roadmap and you can expect to see an update on our Twitter account or Blog soon. |
@leo, no issues with closing this to focus on Issues but where can we track the new solution that you guys have supposedly been working on for some time around env changes??? |
I don't really get why closing. Maybe if we will see some solutions very soon, like within few days, - then I will understand this rush of closing the issue. But for now it's just weird seeing the issue is "just closed", without real reason. First of all, am I only the one noticing the fact @leo thanked himself for creating his issue, and later, with excuses to himself, closed this? How weird is that? Haven't you noticed, @leo, you yourself created that particular issue? I understand the concern of having issue number small. I also understand that ofc there may be some underlaying dev flows, outside of Github. Also, I really like your guys blog, but it seems it's not even possible to have an email subscription for it (unfortunately). Github Issues is one of the best places for tracking software updates, overall. Regarding bugs or features, whatever. Issues are essentially multipurpose, not just for bugs, - that's why they called issues, not bugs. There are tags for that, on github, and also very good search with keywords. So I feel some dishonesty to the community 😒 |
@jerrygreen That looks like an automated closing message. I saw the exact same text a couple of times now and I agree its frustrating. They are going from an open process like GH issues to a closed system via Email. Their support at the email address is very (!) quick to respond though. However I'd like they keep tracking issues here instead of some internal tool (only). On topic, I wonder why I cam here cause I wondered why I am going to create a PR, lets see how it will be received. |
Hey @leo - looks like this was accidentally closed? Any update on how the new env system is progressing? |
@rauchg I feel like I've read half the internet by now and still have no clue how to set this up to work, let alone how to do it "properly". Is there a comprehensive guide how to currently create multiple environments like dev/staging/prod? |
The canonical answer from us in the form of customizable per-environment ENV in our UI is shipping very very soon. Apologies for the delay on this. |
Very exciting! Is there an issue to subscribe to for updates? Thanks! |
Having similar problem when running |
@rauchg it might be more sense to keep this issue open while the functionality is not yet shipped to master branch (I personally prefer this issue to be open, and only closed when the functionality is there, - otherwise it's just harder to track everything... There's a lot of issues, you know, - why just don't close them immediately? P.S. sorry for such an extravagant example though) |
Is there anywhere that we can track the progress for this or opt into a beta version for our deployments? |
YES! I mean... No, there isn't. But this is what I'm whining about, in a message above your one. The issue should be open, to track if/when it's done.
This is not an official answer, but no, there isn't. I'm very into this issue, I would know otherwise. |
I believe you can opt in for beta here |
I created two teams, and each one set secret with different value, and each one watch different git branch ,to solve this issue. |
@ddman i was thinking of doing the same. enabling the feature flag works though! just tested it out. |
Thanks for sharing @alexbudure! Do you know if the beta features also have documentation anywhere or is that only written after a release? |
That's awesome @alexbudure! I've set up the environmental variables using the web UI. Works like a charm! |
@alexbudure Thank you! But looks like my previously stored credentials are not showing up there. Does it mean that I need to create those ones on the web, and remove those |
That's right. It's what I did and it worked. Keep your .env file and |
If I'm understanding this correctly, it only lets us create environment variables that distinguish between a production and a preview deploy. However, if we wanted to have a staging branch that was set to a custom domain (staging.mysite.com), it would still use the production environment variables since this deploys as |
nope! basically all prod deploys if you use the github connection on the default branch will be production env and anything else “preview” deploys will be in the preview env. it works as you’d imagine. just set a domain to a branch that’s not the master/default branch. |
Thank you!! 🥇 Just spent the last 24h looking for how to set prod/preview env variables, and all the solutions are geared towards using now cli, which is a no-go when using now deployment hooks. |
If you are using a monorepo, how can you define which env variables have to go with which apps ? It seems that it was possible before v2 of Now since you could specify env in builds but I don't get how it can be done in v2. |
I'm currently trying to use |
Has the "Environment Variables" option been removed from http://zeit.co/_flags ? I no longer see it? Our project env't variables are geared around using .env files. |
|
After zero-config, we want to solve our environment variable situation.
The main problem right now is that there are two different ways of using env in
now dev
andnow
. We should suggest just one (this could be solved by having a "Dev" toggle in the UI for environment).Furthermore, you currently have
env
andbuild.env
.Also, staging/prod and dev are are problem in general:
https://twitter.com/bitr0t_/status/1152370091155214336?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed&ref_url=https%3A%2F%2Fwww.notion.so%2Fzeithq%2F7a16d63fa31245bab8a7899a7d47f5a7%3Fv%3D1947f17e724d4ee4bc1d0aa95dab2614%26p%3Ddbb63b295d2845918211258cd92a6d8f
The text was updated successfully, but these errors were encountered: