What is the typical use-case for adding --prefix support to a scons build?
Currently I use Variables to persist user options from the command-line, but that requires I use the name PREFIX to be recognized as a variable. The docs show a way to specify the preifx using AddOption but then this option must be specified everytime scons is run: it isn't persisted like the variables.
What is the typical way to handle this?
You will need to use Add/GetOption to create an option the user can provide on the command line.
After, yous users will need to set the environment variable SCONSFLAGS with options they want to provide to SCons everytime. SCons will read this variable everytime.
http://www.scons.org/doc/2.0.1/HTML/scons-user/c2076.html
It's not a good idea to have many environment variable on the user machine because you lost the documentation and which variable you really need to compile.
Related
/bin/node -r /opt/otel/node/otel-agent.js /opt/service/dist/main.js
This is how I am running my application currently.
The problem is, sometimes otel-agent.js might not exist and I want to be able to define a 'Node' agent similar to how you can define various runtime arguments via the env variable
JAVA_TOOL_OPTIONS=javaagent:/opt/otel/java/aws-opentelemetry-agent.jar.
Does such a thing exist for Node?
There is no agent for javascript in OpenTelemetry.
As an alternative, you can use auto instrumentation modules, I would start by looking at the docs for that: https://opentelemetry.io/docs/instrumentation/js/getting-started/nodejs/#instrumentation-modules
NODE_OPTIONS=--require /opt/otel/otel-agent.js
I am trying to test my config files by validating them, nothing fancy, a schema, a list of envs, iterate over it, load the config and validate the variable against the schema.
Problem is, to do that, I currently have to set process.env.NODE_ENV. Since the tests have their own reserved config file, this mean if the tests were run in parrallel, it may happen that the test change the NODE_ENV variable when the other tests are loading the config, which while it doesn't seems likely to happens, still bother me.
A simple solution would be to be able to tell node-config to ignore the environment variable, and use a given value as if it was, something like require('config')('myNodeEnv'), but I couldn't find anything similar in the wiki nor the documentation. The closest is custom env variable, but this would just move the problem to another variable.
Instead of tests having their own config files, tests should load a same "base" test-config.
When a specific test needs to override a specific value it should override that specific value and not the entire config (needless to say, we need to make sure to fix the overridden value when the test finishes).
When we work as described above, it reduces the chances of any collision because the chances that different tests will override the exact same value at the exact same moment is very low.
Another option is to run tests separately, for example:
npm run test:suite1
npm run test:suite2
where test:suite1 could be declared in package.json under scripts section, for example:
"test:suite1": "NODE_ENV=test-conf-1 tests/suite1.js",
...
I need to use a variable between node modules folder and src folder.Is there a way to use a variable to be used within the whole project?
Thanks.
Typically this is done with process environment variables. Any project can look for a common environment variable and handle that case accordingly, as well as the node modules of said project. As long as they agree on the name, they all share the same environment. Have a good default, don't force people to set this environment variable.
The environment can be set using an environment file (do not check this into source control!), on your container or cloud configuration, or even right on the command line itself.
TLOG=info npm test
That is an example that I use frequently. My project runs logging for the test cases only at alert level - there are a lot of tests so it makes the output less verbose. However, sometimes while developing I want to see all the logs, so my project is looking for an environment variable TLOG (short for "test logging") and I can set it just for that run! Also no code change is needed, which is nicer than JavaScript variables that need to be set back to original values, forget to be turned off, etc.
when configuring https for play framework, I have to use following configuration when running the background task.
play -Dhttps.port=9443 -Dhttps.keyStore=keystore.jks -Dhttps.keyStorePassword=password run
I don't want to display the keystore password on the command line. It shouldn't be visible for all users on that machine.
HTTPS configuration can either be supplied using system properties or in application.conf
I recommend to use a combination of environment variables and the application.conf
Put your sensitive information in environment variables
Reference these environment variables from the application.conf:
Like this:
https.keyStore = defaultvalue
https.keyStore = ${?MY_HTTPS_KEY_STORE_ENV}
The question mark means that if there is no value found for MY_HTTPS_KEY_STORE_ENV then the defaultvalue from above will be used
Any environment variable prefixed with "FACTER_" is automatically added to the facter collection. I've successfully added a "FACTER_" environment variable it is indeed showing up in the facter -p list, so it should be able to be used by puppet...
The problem, though, is in my .pp file the variable name that should be set to the FACTER_ value is empty (or non existant)
Is there something else I need to do to get FACTER_ variables into puppet variables?
Cheers
You are most likely setting up the system so that the FACTER_ variables are available in interactive shells. This is not sensible if you want your background agent to respect them.
I can see two direct approaches:
Modify your initscript or its configuration to set the appropriate environment variables.
Forego the approach entirely and use /etc/facter/facts.d instead.
I would advise towards the latter.