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.
Related
First question is supported, to manage add module from one point to all host?
If I run my wildfly domain mode I can't run this
[domain#127.0.0.1:9999 /] module add --name=com.oracle.jdbc --resources=/path/to/ojdbc6.jar --dependencies=javax.api,javax.transaction.api
answer:
The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
The module operation doesn't work in domain mode because it copies the files locally.
One solution also is to use galleon to provision your modules
I found a very good blog:
https://in.relation.to/2017/05/29/creating-patches-for-wildfly/
This works. If you will add a module to modules/com/.. then in the projekt you have to put modules/system/layers/base/com/..
So you can manage the differences of wildfly-s.
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.
I'm going through the "Getting Started with Openshift" guide trying to learn this stuff. I have successfully added and configured a postgres db in my python gear.
If I run an env on the gear itself, I see the database environment variables:
[]\> env |grep POSTGRESQL_DB
OPENSHIFT_POSTGRESQL_DB_HOST=x.x.x.x
OPENSHIFT_POSTGRESQL_DB_USERNAME=admindb
OPENSHIFT_POSTGRESQL_DB_PORT=5432
But in my deployed code, I dump all the env variables with logging.error(os.environ) and none of the POSTGRESQL_DB variables are set. All the python ones seem to load properly.
I know I could set these vars manually, but since these vars are controlled by the gear they could become stale. The documentation implies that these variables should be set (they are used in the sample code).
Found the problem.
In the instructions we set a hot_deploy marker (so the application doesn't bounce when code changes are committed). The next step in the instructions is to add the postgres cartridge, but the environment variables won't load until the cartridge is restarted. So bounce the application and all is well.
Thanks,
Ryan
Is your deployed code running through the same logged-in shell environment as you log in with?
A common solution to making code see shell environment variables that are launched via some non-shell method is to launch them through a login shell.
For example:
/bin/bash -lc "/whatever/you/are/launching --args stuff"
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.
Wondering if it's possible to move the module directory in a JBoss 7 install to a non-default loco.
Does anyone know of a config param to specify where to pick it up?
Kinda like a conf-dir, bin-dir type of thing.
Thanks,
Aaron.
Yes, it's actually possible. As the documentation states, from within the standard launch scripts users are able to manipulate the module path by setting the $JBOSS_MODULEPATH environment variable. (If not set, $JBOSS_MODULEPATH is set to $JBOSS_HOME/modules). The module path is provided to the running process via the -mp command line argument that is set in the standard scripts.