hi!
I wonder if anyone knows if there is any way to force the update of the .env file.
First of all, every time that I modified my .env variables, the changes were happening right away but now I started using the next build configuration:
build: {
hardSource: true,
cache: true,
parallel: true,
}
And ever since I started using those experimental features, the .env variables do not seem to get updated after I update one value in my .env file.
In my project, I develop the API in one machine and the front end on other machine (Just for convenience), so, sometimes my machine has the next IP address: 192.168.100.100 and sometimes 192.168.100.101, etc.
My project uses the environment variable (in the .env file)
API_URL=http://192.168.100.100:4100
BASE_URL=http://localhost:4200
So, when the local IP address of the first machine changes, I have to update the .env file.
The problem now is that even after killing the app, deleting .nuxt folder and running npm run dev I still see the API requests having the previous IP address.
Solutions?
I have thought of disabling the cache and hardSource configurations but they are really helpful to me and the IP changes are not that often, but once in a while I have to update other variable, so that's not a solution for me.
I have also thought of disabling DHCP on my other machine and assigning it a fixed local IP address, but that is not ideal for me, although I think I will do that for now, hoping that in the future I get to know a better way of updating the environment variables (Because sooner or later I will need to update another variable that has nothing to do with the IP address)
I'd like to know if there is a way to force the .env variables to be updated in a nuxt project with hardSource, cache and parallel set to true.
Related
How can I tell if the settings files associated with a Mosquitto instance, have been properly applied?
I want to add a configuration file to the conf.d folder to override some settings in the default file, but I do not know how to check they have been applied correctly once the Broker is running.
i.e. change persistence to false (without editing the standard file).
Test it.
You can run mosquitto with verbose output enabled, which will generally give you feedback on what options were set, but don't just believe that.
To do that, stop running Mosquitto as a service (how you do this depends on you setup) and manually run it from the shell with the -v option. Be sure to point it at the correct configuration file with the -c option.
That's not enough to be sure that it's actually working properly. To do that you need to test it.
Options have consequences or we wouldn't use them.
If you configure Mosquitto to listen on a specific port, test it by trying to connect to that port.
If you configure Mosquitto to require secure connections on a port, test it by trying to connect to the port unsecured (this shouldn't work) and secured (this should work).
You should be able to devise relatively simple tests for any options you can set in the configuration file. If you care if it's actually working, don't just take it on faith; test it.
For extra credit you can bundle the tests up into a script so that you can run an entire test suite easily in the future and test your Mosquitto installation anytime you make changes to it.
Having duplicate configuration options with different values is a REALLY bad idea.
The behaviour of mosquitto is not defined in this case, which value should be honoured, the first found, the last? When using the conf.d directory, what order will the files be loaded in?
Also will you always remember that you have changed the value in a conf.d file in the future when you go looking?
If you want to change one of the defaults in the /etc/mosquitto/mosquitto.conf file then edit that file. (Any sensible package management system will notice the file has been changed and ask what to do at the point of upgrade)
The conf.d/ directory is intended for adding extra listeners.
Also be aware that there really isn't a default configuration file, you must always specify a configuration file with the -c command line option. The file at /etc/mosquitto/mosquitto.conf just happens to be the config file that is passed when mosquitto is started as a service when installed using most Linux package managers. (The default Fedora install doesn't even setup the /etc/mosquitto/conf.d directory)
I'm using Next.js with Vercel. This is my .env.local file:
# Created by Vercel CLI
VERCEL="1"
VERCEL_ENV="development"
VERCEL_URL=""
VERCEL_GIT_PROVIDER=""
VERCEL_GIT_REPO_SLUG=""
VERCEL_GIT_REPO_OWNER=""
VERCEL_GIT_REPO_ID=""
VERCEL_GIT_COMMIT_REF=""
VERCEL_GIT_COMMIT_SHA=""
VERCEL_GIT_COMMIT_MESSAGE=""
VERCEL_GIT_COMMIT_AUTHOR_LOGIN=""
VERCEL_GIT_COMMIT_AUTHOR_NAME=""
I have a component that is trying to access: process.env.NEXT_PUBLIC_VERCEL_ENV to make sure it is on development environment.
This is what I'm getting when running npm run dev.
Logs from the server:
The logs above make perfect sense. Since it's running on the local server to render the pages.
But when my client code tries to do the same, I'm getting:
This is how I'm trying to acess it:
console.log(`process.env.NEXT_PUBLIC_VERCEL_ENV: ${JSON.stringify(process.env.NEXT_PUBLIC_VERCEL_ENV)}`);
console.log(`process.env.VERCEL_ENV: ${JSON.stringify(process.env.VERCEL_ENV)}`);
On client, the VERCEL_ENV should be undefined, but NEXT_PUBLIC_VERCEL_ENV should be development, right?
What could be happening?
UPDATE
I even tried to add NEXT_PUBLIC_VERCEL_ENV="development" to the .env.local file. But so far, the result is the same.
NEXT_PUBLIC_VERCEL_ENV="development"
You will have access to this everywhere (in the browser and Server).
VERCEL_ENV="development"
You only have access to this in the server, in the browser it will show undefined.
Please note after you add or make any changes in the .env.local file you have to restart your server otherwise it will show undefined if you console.log the variables.
Make sure Automatically expose System Environment Variables is checked in your Project Settings.
System Environment Variables
More info in docs
I'm moving a Jenkins from 'traditional' to JCasC.
We have a quite complex setup already, and I am wondering if there is a way to migrate somehow the current configuration without a need of going through settings and code it in .yaml?
btw. I'm not sure about installing JCasC plugin on prod to see the configuration... Am I wrong?
Thanks!
Make sure to have read the Getting Started and other docs.
Create new instance (you can do this onto your desktop/laptop) and copy over all the configuration, config.xml,*.xml, secrets and keys, but NO jobs into the new instance. See what to backup.
Add an entry to start in quiet mode by adding Jenkins.instance.doQuietDown()
You might want/need to change the url and port config too.depending on host. Mind you, you can do this all onto your desktop/laptop
Copy the plugins as well. Add the config as code plugin.
Startup the new instance, export the CasC config and review. The export is a starting point so fill in any missing gaps, etc. For example, since you did not copy jobs over, folders and views will not be created. Some plugin configs are.also not yet implemented.
Stop Jenkins, delete all the config (except the secret key). Put the JCasC config in place and start up. Compare the new configs to what you backed up/copied over. Repeat until they match. Now you should have a config that matches Prod.
Now you can install JCasc in Prod. The plugin does nothing until configured. But do a similar backup/compare of Prod config, before and after the config, just in case something changed in the intervening period
Of course, now you need to mke sure any changes are now only done via JCasC and not the UI, or you are out of sync again. See blog and JEP.
I'm working on an app with vuejs frontend and nodejs backend. My frontend makes API https requests to the backend. I've started my projet with vue-cli and webpack.
I need to get the backend API url from env variable (BACKEND_URL).
Since i'm using webpack, I added this line to config/prod.env.js :
module.exports = {
NODE_ENV: '"production"',
-> BACKEND_URL: JSON.stringify(process.env.BACKEND_URL)
}
It works flawlessly in dev mode using webpack-dev-server. I pass the env var throught docker-compose file:
environment:
- BACKEND_URL=https://whatever:3000
But when I run build, I use nginx to serve the static files (but the problem is the same using visual studio code live server extension). I send BACKEND_URL env var the same way as before. The thing is now the process.env.BACKEND_URL is undefined in the app (but defined in the container)!! So I cant make backend http calls :(
I'm struggling finding the problem, please don't be rude with the responses. Thank you
They aren not "translated" during build time, this is what is happening with you. On a node environment, when you ask for process.env it will show all environment variables available in the system, that is true. But a web application does not have access to process.env when it is executing. You need a way to translate them during build time.
To achieve that you have to use DefinePlugin. It translates anything during build time and writes a magical string where this other thing was.
Using you own example:
module.exports = {
NODE_ENV: '"production"',
BACKEND_URL: JSON.stringify(process.env.BACKEND_URL)
}
If you do this during build time, without DefinePlugin, webpack won't know what to do with it, and it is going to be a simple string.
If you use DefinePlugin:
new webpack.DefinePlugin({
"process.env.BACKEND_URL": JSON.stringify(process.env.BACKEND_URL)
});
By doing this, you are allowing webpack to translate this during build time.
Give this a shot: https://www.brandonbarnett.io/blog/2018/05/accessing-environment-variables-from-a-webpack-bundle-in-a-docker-container/
If I'm understanding your problem correctly, you're serving a webpack bundle using nginx, and trying to access an environment variable from that bundle.
Unfortunately, it doesn't quite work that way. Your JS file has no access to the environment since it's a resource that has been delivered to the client. I've proposed a solution that also delivers those env variables alongside the bundle in a separate JS file that gets created on container start.
From VueJS Docs: https://cli.vuejs.org/guide/mode-and-env.html
Using Env Variables in Client-side Code
Only variables that start with VUE_APP_ will be statically embedded into the client bundle with webpack.DefinePlugin. You can access them in your application code:
console.log(process.env.VUE_APP_SECRET)
During build, process.env.VUE_APP_SECRET will be replaced by the corresponding value. In the case of VUE_APP_SECRET=secret, it will be replaced by "secret".
So in your case, the following should do the trick. I had the same problem once in my project, which I started with vue/cli and vue create project ...
VUE_APP_BACKEND_URL=https://whatever:3000
Not sure how to ask this question but would like to put it here and want to hear some suggestions.
So far, I use "DB_LINK" variable that has mongo database url in my config.json file. My Node app uses this variable to connect to the Mongo. But this DB_LINK also gets checked into git, which we dont want this to happen because we dont want to check in the passwords into git.
in my local development, I use local.json file that has all these configs and not check that file into git (in .gitignore entry). So it is fine making it work in my local dev environment, but the challenge is when Jenkins try to push the code to TEST, it has to pass testcases (it has to run test cases, so that time the DB_LINK value is needed) before deployment happens. so this is when I need this DB_LINK variable be passed from Jenkins.
Here is what I did so far ..
in Jenkins configurations, at the 'predefined parameters' I added DB_LINK=myMongoLink to parameters list.
but this value is not being handed over to my node app. Any suggestions on how to achieve what I am trying to achieve?
Ok. I figured this out. before the change, I used to pass a command from Jenkins to run my test cases like this
npm run test
but now,
DBLink=myDB npm run test
so the DBLink variable from here being handed over to the node app and was able to run the test cases. Before this change,
I used to pass this DBLink=myDB from a config file