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",
...
Related
Disclaimer: I can achieve the behavior I’m looking for with Active Choices plugin, BUT I really want this to work in a Jenkinsfile and controlled with scm because it’s tedious to configure the Active Choices on each job we may need them on. And with it being separate from the Jenkinsfile creation, it’s then one job defined in multiple places. :(
I am looking to verify if this is possible, because I can’t get the syntax right, if it is possible. And I haven’t been able to find any examples online:
pipeline {
environment {
ARTIFACTS = lib.myfunc() // this works well
}
parameters {
choice(name: "Artifacts", choices: ARTIFACTS) // I can’t get this to work
}
}
I cannot use the function inline in the declaration of the parameter. The errors were clear about that, but it seems as though I should be able to do what I’ve written out above.
I am not home, so I do not have the exceptions handy, but I will add them soon. They did not seem very helpful while I was working on this yesterday.
What have I tried?
I’ve tried having the the function return a List Because it requires a list according to the docs, and I’ve also tried (illogically) returning a String in the precise syntax of a list of strings. (It was hacky, like return "['" + artifacts.join("', '") + "']" to look like ['artifact1.zip', 'artifact2.zip']
I also tried things like "$ARTIFACTS" and ${ARTIFACTS} in desperation.
the list of choices has to be supplied as String containing new line characters (\n): choices: 'TESTING\nSTAGING\nPRODUCTION'
I was tipped off by this article:
https://st-g.de/2016/12/parametrized-jenkins-pipelines
Related to a bug:
https://issues.jenkins.io/plugins/servlet/mobile#issue/JENKINS-40358
:shrug:
First, we need to understand that Jenkins starts running your pipeline code by presenting you with Parameters page. Once you've set up the parameters, and pressed Build, then a node is allocated, variables are set, and your code starts to run.
But in your pipeline, as presented above, you want to run some code to prepare the parameters.
This is not how Jenkins usually works. It's definitely not doing the following: allocating a node, setting the variables, running some of your code until parameters clause is reached, stopping all that, presenting you with GUI, and then continuing where it left off. Again, it's not how Jenkins works.
This is why, when writing a new pipeline, your first option to build it is Build and not Build with Parameters. Jenkins hasn't run your code yet; it doesn't have any idea if there are any parameters. When running for the first time, it will remember the parameters (and any choices, if were) as were configured for this (first) run, so in the second run you will see the parameters as configured in the first run. (Generally, in run number n you will see the result of configuration in run number n-1.)
There are a number of ways to overcome this.
If having a "somewhat recent" (and not "current and absolutely up-to-date") situation fits you, your code may need minor changes to work — second time. (I don't know what exactly lib.myfunc() returns but if it's a choice of Development/Staging/Production this might be good enough.)
If having a "somewhat recent" situation is an absolute no-no (e.g. your lib.myfunc() returns the list of git branches, and "list of branches as of yesterday" is unacceptable), then your only solution is ActiveChoice. ActiveChoice allows you to run some code before showing you the Build with Parameters GUI (with script approval etc.).
I am trying to perform system update from command line with a json config but it seems that, no matter what I do,
the command does the exact same thing, which I suppose is running the update with the default platform settings.
For example, when I tried to perform my update without essential data("essential": "false" in json config), essential impexes are also being run.
I tried with an invalid json(that does not have json format) and the build was successfull.
I also tried giving as a paramter a json that does not exist and yet, the build was successfull and essential impexes were also run.
So, it seems to me that, no matter what I do, the json is not taken into account and the update works with the default platform settings.
This is the command I am using:
ant updatesystem -Dtenant=master -DconfigFile=Path/updatesystem.json
Am I doing something wrong or how can I pass my configuration during system update from command line ?
PS:
Hybris version: 6.7.0.25
I Think your JSON path is wrong and please try to do it like this.
ant updatesystem -DconfigFile=../custom/testcore/resources/updatesystem-configuration.json
The problem was caused by the fact that the "updatesystem" macro was overriden in a project specific file and the configFile property was not passed to the UpdatePlatformAntPerformableImpl during creation. That is why, regardless of my input for configFile property , nothing changed.
I fixed the problem by also passing the configFile in the constructor:
new de.hybris.ant.taskdefs.UpdatePlatformAntPerformableImpl("${tenant}", "${configFile}")
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.
Sample situation
I have my own Yeoman generator, which has a folder with "template" of the resulting project.
The generator takes some information from user, interpolates the "template" with the information and then outputs a simple working project.
I want to ensure the "template" is actually working, at least in one positive scenario if not with all combination of inputs. I can write integration tests (which will run the generator with some data and then try to run the resulting code and verify whether all works as expected), but still, that's sometimes too much work and it's inconvenient for trial and error kind of development or some prototyping.
Question
Is there an easy way how to work with the "template" itself, how to run it or use it locally, manually, without the need to run the generator first every time I change a single letter in files of the "template"?
Maybe some sort of build step, which would run the generator for me with some preset data? Is there anything ready in form of npm module? Does a best practice exist?
After running the integration test, you can spawn some commands in the generated project folder and see if those are passing fine.
So far, the best solution I found is to create a script, which:
Creates a temporary sandbox directory.
Performs npm link
Alters the PATH so it does not contain .bin of your local node_modules (this is needed to prevent locally installed Yeoman take precedence over the global one when the script is ran e.g. as npm run develop).
Sets an environment value NON_INTERACTIVE to something truthy.
Runs yo <your generator> in the sandbox directory.
Runs npm start in the sandbox directory to run the freshly generated server code.
Change your generator so it is able to automatically provide some dummy default values for required prompts without default values if process.env.NON_INTERACTIVE is truthy.
Then run the script as:
$ nodemon --watch <directory with your template> --exec <path to your script> --ext js
It's slow, but it works. This way you can develop the template itself and avoid filling the generator every time you need to try out something.
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.