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}")
Related
The version of Node.js I used is 10.21.0. I modified BUILD.gn under deps/v8 folder: I set V8_TRACE_IGNITION=true and I rebuilt Node.js using ./configure after that. Then I run "node --trace-ignition xx.js". I expected to trace the ignition's behavior. But it said bad option. I was wondering where I did wrong.
I was wondering where I did wrong.
To get an answer to that, you'd have to describe exactly what you've done, e.g. by posting the patch showing your edits to the file.
That said, modifying BUILD.gn is not necessary to get --trace-ignition to work. Simply use gn args out/<your_output_dir> to edit your build settings as usual, and add v8_enable_trace_ignition = true.
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've been following this Suave tutorial:
https://legacy.gitbook.com/book/theimowski/suave-music-store/details
And in general this looks good. However, I was trying to make it work with Linux and for some reason I was unable to compile it with code when TargetFramework was set to "net461" (Target Framework not found), so I tried changing it to "netcoreapp2.0". It compiled, but I hit a problem later on:
https://theimowski.gitbooks.io/suave-music-store/content/en/css.html
At the end it says to add a WebPart:
pathRegex "(.*)\.(css|png)" >=> Files.browseHome
which fails for me. All compiles, but I get
This page isn’t working
localhost didn’t send any data.
I took a look at Suave's source code and it turned out that "Files.browseHome" searches for a file under "ctx.runtime.homeDirectory".
I noticed that this is set on my machine to:
/home/<my_user_name>/.nuget/packages/suave/2.2.1/lib/netstandard1.6
and obviously, that's not my project directory, so no wonder it couldn't find the file.
My question here is: what shall I do in order to make my Suave app handle my css/png files correctly using Files.browseHome ?
EDIT:
Just found out that replacing the WebPart with:
pathRegex "(.*)\.(css|png)" >=> Files.browse "/home/<my_username>/<path_to_my_project>/bin/Debug/netcoreapp2.0/"
works fine, but it looks ugly. Any idea how to make it better ? Basically I don't want to be forced to hardcode the absolute path anywhere.
I think the answer is to be found in https://suave.io/files.html, which suggests creating a config as follows:
let config =
{ defaultConfig with homeFolder = Some (Path.GetFullPath "./public") }
The path returned by Path.GetFullPath will depend on the current working directory that your app sees when it's started (which will, in turn, depend on how you start the app: from the command line, from a systemd unit file, etc.) There are too many possible variables here for me to be able to give you exact instructions, but if your startup method can cd into an appropriate folder before starting your Suave server, then that should solve your problem.
If you run into difficulties with getting the current working directory set correctly, then you could just hardcode the full path in the config:
let config =
{ defaultConfig with homeFolder = Some "/home/<your_username>/<path_to_your_project>/bin/Debug/netcoreapp2.0/" }
But that's kind of ugly, and not really portable (you'd have to modify that path again once you deploy the app). So I'd recommend the approach of making sure your start script does a cd to the right location, then using Path.GetFullPath with a relative path. Alternately, you could have a config file that gets read in at app startup where you specify the home path, or pass it in as an environment variable... All kinds of possibilities. Just make sure that your code can be handed some information on startup that specifies the correct "home" folder, and then put that in your Suave config as I've shown, and that should solve it.
I am using LoadUI 2.6.8 and SoapUI 5.0.
I have been able to do Property Transfers into Test Case properties that are successfully passed between SoapUI Runners in LoadUI as described here: http://www.loadui.org/soapui-integration/passing-along-testcase-properties.html
The problem I am having is that one of the properties I am setting via a Groovy Script like this:
def tc = testRunner.testCase.testSuite.getTestCaseByName("Auth and Start Up")
tc.setPropertyValue("Cookie","$jsesid")
is not being updated in LoadUI (when the groovy script runs) and thus not being passed around properly.
I have to use a groovy script because the cookie comes in as part of the response header and the normal Property Transfer Step doesn't allow me to do the transfer.
Has anyone encountered this before? Any insight into why this would be happening?
Thanks!
UPDATE: I managed to get around this issue by updating the Authentication API response to include the cookie as part of the response body (instead of just the header) and thus I was able to use the Property Transfer step which seems to work. This is still a workaround though.
Thanks for the link SiKing, I think I actually ran across that while trying to figure out the cookies, which I eventually managed to get working by setting the headers manually using the script. In order to test if it was a cookie issue I used another property. I added the following line to the groovy script:
tc.setPropertyValue("testprop","blah")
ran it in SoapUI and the property value is set ok. I then changed the value of the test case property "testprop" in the SoapUI test case to "a" manually and saved the project.
In LoadUI I ran the SoapUI Runner and the output for this property shows as "a" eventhough the groovy script ran fine. The more I play around with it the more I think its some kind of bug in LoadUI :(
I am Using CC.Net to run an .exe file after project build is complete and need to pass the project name, publish date/time and user on the command line as parameters to the .exe. However I can't get cc.net to recognise these a dynamic properties and replace them with the correct values.
<publishers><exec executable="C:\MyApp.exe"></exec><buildArgs>"$[$CCNetProject]" "$[$CCNetBuildDate]" "$[$CCNetBuildTime]" "$[$CCNetUser]"</buildArgs><buildTimeoutSeconds>30</buildTimeoutSeconds></publishers>
The correct syntax for properties in ccnet config is $[CCNetProject]
I believe the correct syntax for properties in ccnet config is:
$[CCNetProject]
Rather than:
$[$CCNetProject]