Laravel is pretty clear on how to set up environment specific config.
It also has a method for creating package configuration
What I have not been able to find is an example of creating environment specific package configuration. Is there a way to do this?
If your production app package config is here:
/app/config/packages/{name}/{package}/config.php
Then you just add an environment specific subfolder(s), same as you do for other configs:
/app/config/packages/{name}/{package}/local/config.php
/app/config/packages/{name}/{package}/testing/config.php
And just overwrite any production values with the specific environment variables you need.
Related
I have Angular 7 application. I'm building it and generating Dist package. I would like to deploy this package on Tomcat or Apache web-server.
Now, I do not want to hard-code any values in app.config.json file. I would like to externalize these properties. Let's say, i have server.xml file or any other file in tomcat and values should be there and app.config.json should read property values from there.
How can I achieve this? Is there any other way, I can externalize my properties?
Maybe this can help you https://itnext.io/how-does-app-initializer-work-so-what-do-you-need-to-know-about-dynamic-configuration-in-angular-718e7c345971.
Using this approach you can provide your configuration file directly to container (Tomcat or Apache Server) independently on environment.
If you use k8s, you can provide this config file through ConfigMap.
I am begining to work with ORIENTDB and I have the following question.
Is it mandatory to set both environment variables? I was hoping to work with the studio without them, just setting the XML with my own environment variables.
Is there anyway to use custom variables programatically in my Java program?
Regards.
You don't need to set environment variables to work with OrientDB unless you're planning to run it from outside of its /bin directory, such as a service.
OrientDB Docs | Windows Service
OrientDB Docs | Unix Service
I finally understood what is missing.
When the "OServerPluginManager" is at startup, it uses the ORIENTDB_HOME setted + "plugins" to check the directory and register the plugins.
But between setting the plugin directory using the environment variable and registering the plugins, there is a overriding of properties checking the Server Property "plugin.directory".
So adding the property at server level with the directory where the plugins are will fix the problem.
In laravel configuration variables can be accessed like this
Config::get('xxx')
By default it returns the configuration values for the current environment. How do you get configuration data for other environments?
A call to Config::get() will already get you information of your current environment, if you are in dev it will be dev, if you are in production it will be the production data.
If you need to get a configuration information about another environment you can do by:
return Config::get('environment/config.name');
Example:
return Config::get('testing/cache.driver');
If you need to get things from your production environment while being in any other one, I'm afraid you'll have to create a 'production' folder inside your config folder and put those things there:
app/config/production/database.php
Add to that particular file only what you need to read outside from your environment:
'default' => 'postgresql',
And then you'll have access to it:
return Config::get('production/database.default');
You should be able to just do Config::get('xxx');
Unless you are overriding it in your testing/local/develop environments it should always be available. If you are, just remove it from the other envs.
I cannot see why you would define a config variable in another environment but then still need the production config.
I am looking into a way of defining an environment variable for Hudson (NCover path on build server), so that build scripts can use it, but no need to re-define it in Hudson jobs (similar to %SVN_REVISION% or %BUILD_NUMBER%). What would be the way of doing it?
Thank you.
You can set node variables, that will be available to every job that runs on that node. Go to the node configuration page, and you'll see it. For the master node, the environment variables are configured on Hudson's main configuration screen.
If it's global (same on every node), you can add environment variables for every build in Manage Hudson -> Configure System, under Global Properties -> Environment Variables
Updated: Oops, sorry, didn't notice that #Michael Donohue had already said this.
I am creating a dtsx package that I am running through a bat file. At design time, I created a package configuration that points to a specific location. When I am running the package at run-time, however, I am setting the ConfigFile to a package configuration in a different location. It appears, however, that the package is still running off of the configuration set at design time. Does any one know why this might happen? Any ideas on how I can get the package to run with this different configuration? The following is what I am running in my bat file.
dtexec.exe /f "mypackage.dtsx" /ConfigFile "[some_path]/newconfig.dtsConfig"
If you are using SQL Server 2008, then the order in which package configurations are applied in is as follows:
Design-time configurations
Run-time configurations (i.e. those specified by the /ConfigFile parameter
Design-time configurations again
Therefore any variables set in the design-time config cannot be changed using the /ConfigFile parameter.
The official solution to this is to change the path to the design-time configuration using the /Set parameter.
Details on this can be found here: http://msdn.microsoft.com/en-us/library/bb500430.aspx
I suggest having different sets of .dtsconfig files per environment (DEV, QA, PRD) and to register them as Environment Variables on the machines using setx batch command to define the Variable name and file path.
By using the same Environment Variables names on all environments you will mitigate the need to specify the .dtsconfig file at runtime.