I need to run newman-reporter-htmlextra for the same execution with different settings (One with ShowErrorsOnly=true while other as false). The newman.run commands accept different reporters in an array, but I want the same reporter to execute twice with a different config. How can this be achieved? I tried something as follows, but it didn't work:
newman.run({...
reporters: ["htmlextra","htmlextra"],
reporter: {
htmlextra: {
export: "./reports/FULL.html",
showOnlyFails: false,
},
htmlextra: {
export: "./reports/ERRORS.html",
showOnlyFails: true,
},
...
Related
There are 3 types of metadata CDK is writing to CFN. Version, Path, and Assets.
There's documentation on how to disable version metatadata and it works fine, but i'm struggling with the rest. CLI options --path-metadata false --asset-metadata false work fine, but are kind of annoying.
I've been through CDK Source code trying to figure out key words to plug into cdk.json, but they are ignored. The following is verbose cdk output where it reads my settings and seems to ignore the 2 i care about.
cdk.json: {
"app": "python app.py",
"versionReporting": false, <-- custom, works as intended
"assetMetadata": false, <-- custom, doesn't seem to do anything
"pathMetadata": false, <-- custom, doesn't seem to do anything
"context": {
"#aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId": true,
"#aws-cdk/core:stackRelativeExports": "true",
"#aws-cdk/aws-rds:lowercaseDbIdentifier": true,
"#aws-cdk/aws-lambda:recognizeVersionProps": true,
"#aws-cdk/core:bootstrapQualifier": "myQualifier",
"aws:cdk:enable-path-metadata": false, <-- custom, produces namespace warnings
"aws:cdk:enable-asset-metadata": false, <-- custom, produces namespace warnings
}
}
merged settings: { <------------results of combined settings
versionReporting: false, <-- worked
pathMetadata: true, <--didn't work
output: 'cdk.out',
app: 'python app.py',
assetMetadata: true, <--didn't work
context: {
'#aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId': true,
'#aws-cdk/core:stackRelativeExports': 'true',
'#aws-cdk/aws-rds:lowercaseDbIdentifier': true,
'#aws-cdk/aws-lambda:recognizeVersionProps': true,
'#aws-cdk/core:bootstrapQualifier': 'myQualifier',
'aws:cdk:enable-path-metadata': false, <-- seems like a dud
'aws:cdk:enable-asset-metadata': false,<-- seems like a dud
},
debug: false,
profile: 'mycdkIAMUser',
toolkitBucket: {},
staging: true,
bundlingStacks: [ 'my-cdk-policies' ],
lookups: true
}
Looking at the CDK source code, it seems as if the CLI options are currently the only viable option.
Have a look at execProgram() lines 23 to 31:
const pathMetadata: boolean = config.settings.get(['pathMetadata']) ?? true;
if (pathMetadata) {
context[cxapi.PATH_METADATA_ENABLE_CONTEXT] = true;
}
const assetMetadata: boolean = config.settings.get(['assetMetadata']) ?? true;
if (assetMetadata) {
context[cxapi.ASSET_RESOURCE_METADATA_ENABLED_CONTEXT] = true;
}
The CLI options both default to true, which then override their respective context variables. Might warrant a bug report.
What does this ui: "ui#http://some.external.host/remoteEntry.js" syntax mean in ModuleFederationPlugin's remotes property.
I understand that ui item is being loaded from an external host, but what does ui# before host definition mean ?
new ModuleFederationPlugin({
name: "myApp",
filename: "myAppEntry.js",
remotes: {
ui: "ui#http://some.external.host/remoteEntry.js",
},
shared: {
...,
},
}),
You can break this line of the config ui: "ui#http://some.external.host/remoteEntry.js" into three parts: LocalModuleName: "RemoteModuleName#Host". Let's assume myApp and ui have the following webpack configs for module federation:
// Config for myApp
new ModuleFederationPlugin({
name: "myApp",
filename: "myAppEntry.js",
remotes: {
ui: "ui#http://some.external.host/remoteEntry.js",
},
shared: {...},
}),
// Config for ui
new ModuleFederationPlugin({
name: "ui",
filename: "remoteEntry.js",
exposes: {
"./Button": "./src/Button",
},
shared: {...},
}),
LocalModuleName is the name under which you can import exposed features from the remote app in the local code, e.g.:
const RemoteButton = React.lazy(() => import("ui/Button"));
But you could also change the name to remoteUI: "ui#http://some.external.host/remoteEntry.js" and the import would have to look like this:
const RemoteButton = React.lazy(() => import("remoteUI/Button"));
This could be useful if two different remotes used the same name in their config.
RemoteModuleName refers to the name used in the remote configuration. This is necessary, so ModuleFederation can properly initialize the modules.
Host is the URL under which you find the remote container script.
Hi I am trying to use torii in a cordova application. My environment.js file looks as below. I an not able to access window document object to setup redirectUri. getting error undefined variable. how can I access window document object.
module.exports = function (environment) {
var ENV = {
environment: environment,
baseURL: '/',
locationType: 'hash',
EmberENV: {
FEATURES: {
// Here you can enable experimental features on an ember canary build
// e.g. 'with-controller': true
}
},
APP: {
// Here you can pass flags/options to your application instance
// when it is created
},
torii: {
providers: {
'facebook-oauth2': {
apiKey: '2xxxxxxxxxx',
redirectUri: document.location.href
},
}
},
cordova: {
rebuildOnChange: false,
rebuildAsync: false,
emulate: false
}
};
in my .jshintrc
"predef": {
"document": true,
"window": true,
"AuthENV": true
}
so I assume document should be globally available but it is not
You are able to access the window and document object through most of your Ember.js code as global variables.
In this particular file, you are trying to access it in use for the app config. The problem is that the config is generated during the Node.js build process - meaning that the context is not the same.
You will see in the page source of your app that the config is static and serialized into a meta property in the page:
<meta name="[your-app]/config/environment" content="your-config-here" />
As the redirect url will change dynamically depending on the user's location, it would be easier to pull in this data "just in time" for the OAuth flow.
I'm hopelessly trying to make the Dijit template inlining functionality of Dojo builds for my AMD project work with no luck yet ...
The particular issue isn't the inlining of the HTML templates themselves, but the fact that they are still requested with Ajax (XHR) after being successfully inlined.
Templates are inlined the following way :
"url:app/widgets/Example/templates/example.html": '<div>\n\tHello World!</div>'
The Dijit widget itself, after building, defines templates like this :
define("dojo/_base/declare,dijit/_Widget,dojo/text!./templates/example.html".split(","), function (f, g, d) {
return f("MyApp.Example", [g], {
templateString: d,
});
});
I tried to build with :
the shrinksafe / closure optimiser
relative / absolute paths
using the old cache() method
using the templatePath property
but even after having run a successful build (0 errrors and a few warnings) where the templates were inlined, Dojo / Dijit still makes Ajax requests to these resources.
Here is my build profile :
var profile = {
basePath: '../src/',
action: 'release',
cssOptimize: 'comments',
mini: true,
optimize: 'closure',
layerOptimize: 'closure',
stripConsole: 'all',
selectorEngine: 'acme',
internStrings: true,
internStringsSkipList: false,
packages: [
'dojo',
'dijit',
'dojox',
'app'
],
layers: {
'dojo/dojo': {
include: [
'app/run'
],
boot: true,
customBase: true
},
},
staticHasFeatures: {
'dojo-trace-api': 0,
'dojo-log-api': 0,
'dojo-publish-privates': 0,
'dojo-sync-loader': 0,
'dojo-xhr-factory': 0,
'dojo-test-sniff': 0
}
};
Due to this issue my application is completely unusable because there are so many files to download separately (browsers have a limit on the number of parallel connections).
Thank you very much in advance !
UPDATE :
The two lines loading dojo.js and the run.js in my index.html :
<script data-dojo-config='async: 1, tlmSiblingOfDojo: 0, isDebug: 1' src='/public/dojo/dojo.js'></script>
<script src='/public/app-desktop/run.js'></script>
Here is the new build-profile :
var profile = {
basePath: '../src/',
action: 'release',
cssOptimize: 'comments',
mini: true,
internStrings: true,
optimize: 'closure',
layerOptimize: 'closure',
stripConsole: 'all',
selectorEngine: 'acme',
packages : [
'dojo',
'dijit',
'app-desktop'
],
layers: {
'dojo/dojo': {
include: [
'dojo/request/xhr',
'dojo/i18n',
'dojo/domReady',
'app-desktop/main'
],
boot: true,
customBase: true
}
},
staticHasFeatures: {
'dojo-trace-api': 0,
'dojo-log-api': 0,
'dojo-publish-privates': 0,
'dojo-sync-loader': 0,
'dojo-xhr-factory': 0,
'dojo-test-sniff': 0
}
};
My new run.js file :
require({
async: 1,
isDebug: 1,
baseUrl: '/public',
packages: [
'dojo',
'dijit',
'dojox',
'saga',
'historyjs',
'wysihtml5',
'app-shared',
'jquery',
'jcrop',
'introjs',
'app-desktop'
],
deps: [
'app-desktop/main',
'dojo/domReady!'
],
callback: function (Main) {
debugger;
var main = new Main();
debugger;
main.init();
}
});
and my main.js file looks like this :
define([
'dojo/_base/declare',
'app-desktop/widgets/Application',
'app-desktop/config/Config',
'saga/utils/Prototyping',
'dojo/window',
'dojo/domReady!'
], function (declare, Application, ConfigClass, Prototyping, win) {
return declare([], {
init: function() {
// ... other stuff
application = new Application();
application.placeAt(document.body);
// ... some more stuff
}
});
});
In build-mode, I get the following error :
GET http://localhost:4000/app-desktop/run.js 404 (Not Found)
which is weird because it means that the build process made it so that dojo has an external dependency rather than an a already inlined dojoConfig variable in the builded file.
In normal-mode, files get requested, but the app is never created.
In both cases none of the two debuggers set in the run.js file were run which means that the callback method was never called for some reason.
Thank you for your help !
I've printed values of requireCacheUrl and require.cache to console in the method load() of dojo/text.js. At least in my case, keys of my templates in the cache differs from lookup keys on one leading slash.
For example, I have "dojo/text!./templates/Address.html" in my widget. It present with key url:/app/view/templates/Address.html in the cache but is searched like url:app/view/templates/Address.html, causing cache miss and xhr request.
With additional slash in dojo/text.js (line 183 for version 1.9.1) it seemingly works (line would looks like requireCacheUrl = "url:/" + url).
Not sure what kind of bugs this "fix" could introduce. So, it probably worth to report this issue to dojo folks.
UPD: Well, I see you've already reported this issue. Here is the link: https://bugs.dojotoolkit.org/ticket/17458.
UPD: Don't use hack described above. It was only attempt to narrow issue. Real issue in my project was with packages and baseUrl settings. Initially I created my project based on https://github.com/csnover/dojo-boilerplate. Then fixed it as in neonstalwart's sample.
This sounds like https://bugs.dojotoolkit.org/ticket/17141. If it is, you just need to update to Dojo 1.9.1.
I am new to Intern and struggling with trying to get a simple test to run in my environment. I was able to get the tutorial test to run but I've tried to set up a test where the test file is located inside my app directory hierarchy. The module being tested is located here:
sandbox/web/libs/ev/grids/FilterGrid.js
The test file is located here:
sandbox/web/libs/ev/tests/FilterGrid.js
My intern config file is located here:
sandbox/tests/intern.js
My loader and suites objects looks like this:
loader: {
packages: [
{ name: 'dojo', location: 'web/libs/dojo' },
{ name: 'dijit', location: 'web/libs/dijit },
{ name: 'dgrid', location: 'web/libs/dgrid' },
{ name: 'put-selector', location: 'web/libs/put-selector' },
{ name: 'xstyle', location: 'web/libs/xstyle' },
{ name: 'ev', location: 'web/libs/ev' }
]
},
suites: ['ev/tests/FilterGrid'],
When the loader tries to load this, I get:
Defaulting to "console" reporter
ReferenceError: document is not defined
at /home/bholm/Projects/src/sandbox/web/libs/dojo/selector/_loader.js:5:15
at execModule (/home/bholm/Projects/src/sandbox/node_modules/intern/node_module
/dojo/dojo.js:512:54)
at /home/bholm/Projects/src/sandbox/node_modules/intern/node_modules/dojo/dojo.js:579:7
at guardCheckComplete (/home/bholm/Projects/src/sandbox/node_modules/intern/node_modules/dojo/dojo.js:563:4)
at checkComplete (/home/bholm/Projects/src/sandbox/node_modules/intern/node_modules/dojo/dojo.js:571:27)
at onLoadCallback (/home/bholm/Projects/src/sandbox/node_modules/intern/node_modules/dojo/dojo.js:653:7)
at /home/bholm/Projects/src/sandbox/node_modules/intern/node_modules/dojo/dojo.js:746:5
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
Does the unit tests using Intern need a DOM document defined??
I also notice that Intern lists dojo2_core as it's dependency. So it's using unreleased code?
Any help with this would be appreciated!
It looks like you’re trying to load some code using the Node.js client that requires a browser environment. This won’t work. You should only load the ev/tests/FilterGrid test suite in a browser. You can do this by modifying your Intern configuration file to look something like this:
define([ 'intern/node_modules/dojo/has' ], function (has) {
var suites = [];
if (has('host-browser')) {
suites.push('ev/tests/FilterGrid');
}
return {
// ...your existing configuration...
suites: suites,
// ...
};
});