-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Add fileExport capability #352
Conversation
- Some tools, such as Support Assistant, provide extra reports directly from tests using a window._$files variable; this is no longer read anywhere and such reports are currently unsupported - See https://github.com/SAP/openui5/blob/master/src/sap.ui.core/src/sap/ui/core/support/RuleEngineOpaExtension.js#L243 - this adds mechanism to read and save these the variable as files using a custom reporter with some additions to browser.js to 'send' the results as part of karma.complete argument
Improve mechanism of writing files to prevent overwriting of existing files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few small suggestions. Otherwise LGTM
README.md
Outdated
Type: `boolean` or `object` | ||
Default: `false` | ||
|
||
Configures whether report files provided by tools like the UI5 Support Assistant are exported to the file system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Configures whether report files provided by tools like the UI5 Support Assistant are exported to the file system. | |
Configures whether report files provided by tools like UI5 Support Assistant are exported to the file system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
README.md
Outdated
} | ||
``` | ||
|
||
Projects can also add report files by itself by setting or enhancing the global `window._$files` array in the executed source code on the following way: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Projects can also add report files by itself by setting or enhancing the global `window._$files` array in the executed source code on the following way: | |
Projects can also add report files by themselves by setting or enhancing the global `window._$files` array in the executed source code in the following way: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@@ -267,6 +267,35 @@ module.exports = function(config) { | |||
}); | |||
};`, | |||
|
|||
invalidFileExportReporterUsage: () => `error 21: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
invalidFileExportReporterUsage: () => `error 21: | |
invalidFileExportReporterUsage: () => `Error 21: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not take over this suggestion to be consistent to the existing error messages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine, but could we have a central resources file (like i18n) where all error messages are stored and can be easily modified? Then we could easily fix such things without having to sacrifice consistency.
@@ -267,6 +267,35 @@ module.exports = function(config) { | |||
}); | |||
};`, | |||
|
|||
invalidFileExportReporterUsage: () => `error 21: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine, but could we have a central resources file (like i18n) where all error messages are stored and can be easily modified? Then we could easily fix such things without having to sacrifice consistency.
if (config.fileExport) { | ||
const testPageName = getTestPageName(qunitHtmlFile); | ||
(testWindow.contentWindow._$files || []).forEach((file) => { | ||
file.name = `TEST-${testPageName}-FILE-${file.name}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this how it was done in Selenium? I.e. with the strings "TEST" and "FILE"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this format is taken from the java implementation
lib/fileExportReporter.js
Outdated
} | ||
|
||
const fileExtension = path.extname(fileName); | ||
const fileNameWithoutExtension = fileName.slice(0, fileName.lastIndexOf(fileExtension)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternative:
const fileNameWithoutExtension = fileName.slice(0, fileName.lastIndexOf(fileExtension)); | |
const fileNameWithoutExtension = path.basename(fileName, fileExtension); |
See https://nodejs.org/api/path.html#pathbasenamepath-ext
But I wouldn't mind the current solution as well 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea but not an alternative because path.basename would trim the starting directory path
lib/fileExportReporter.js
Outdated
} | ||
|
||
for (const file of result.exportFiles) { | ||
const pathSegments = [outputDir, file.name]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const pathSegments = [outputDir, file.name]; | |
const pathSegments = [outputDir, path.basename(file.name)]; |
"sanitize" file name to ensure it is really only a file name and not a path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
lib/fileExportReporter.js
Outdated
for (const file of result.exportFiles) { | ||
const pathSegments = [outputDir, file.name]; | ||
if (multiBrowsers) { | ||
pathSegments.splice(1, 0, browser.name); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pathSegments.splice(1, 0, browser.name); | |
pathSegments.splice(1, 0, path.basename(browser.name)); |
Same for browser name I guess
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
lib/fileExportReporter.js
Outdated
outputDir = defaultPath; | ||
} | ||
|
||
outputDir = helper.normalizeWinPath(path.resolve(config.basePath, outputDir)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure, but I think normalization should happen before any platform specific path
-action?
path.resolve
won't actually resolve two Windows paths on a POSIX system, it will just append them. This might not be expected since on Windows the paths will actually be resolved in that case.
We need to normalize the configuration since it can be POSIX or Windows or both. Later when we path.join
the file path, it will automatically be transformed into the right format for the current platform.
Maybe:
outputDir = helper.normalizeWinPath(path.resolve(config.basePath, outputDir)); | |
outputDir = path.posix.resolve(helper.normalizeWinPath(config.basePath), helper.normalizeWinPath(outputDir)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, a simple path.join should be sufficient since we already expect in browser.js the basePath to be in posix format.
I looked at the changes and also retested this manually - everything seems to be still working as required for further processing of the files, the naming changes did not cause any unexpected trouble so far. Great job! I will continue watching this and give feedback if required, but it seems like this is in good hands now. As the original committer I can't explicitly 'approve' this, so have at least a 👍 from me. |
lib/fileExportReporter.js
Outdated
baseReporterDecorator(this); | ||
|
||
async function writeSingleFile(outputFile, content) { | ||
log.info(`Writing file: ${outputFile}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't output the final path, as getUniqueFileName is called after.
Also, I think it would be sufficient to only have one "info" log per file, so this log should rather become "debug".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
lib/fileExportReporter.js
Outdated
return; | ||
} | ||
|
||
for (const file of result.exportFiles) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to add some error handling here?
Not only in case exportFiles
is not an array, but also when name
or content
are undefined or define an unexpected type.
Currently, no name causes "undefined" to be used as name, and if content is not of type string, it causes an exception. I'd suggest to check for type string and log a warning if a file is not written.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might check out the Java implementation. Just search for LOGGER.severe("Invalid file object. \"name\" and \"content\" must be strings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
lib/fileExportReporter.js
Outdated
} | ||
|
||
for (const file of result.exportFiles) { | ||
const pathSegments = [outputDir, path.basename(file.name)]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Java we escaped the name to remove special characters and slashes:
result = result.replaceAll("[:*?\"<>|]", "");
result = result.replaceAll("[\\\\/]", ".");
Not sure whether we should just stick with that.
path.basename
will still cause strange behavior when using ..
.
My question would be whether we want to make this "safe" so that it can't be misused or just that strange file names don't cause errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
lib/fileExportReporter.js
Outdated
for (const file of result.exportFiles) { | ||
const pathSegments = [outputDir, path.basename(file.name)]; | ||
if (multiBrowsers) { | ||
pathSegments.splice(1, 0, path.basename(browser.name)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for browser.name, we could use the behavior as karma-coverage
does: https://github.com/karma-runner/karma-coverage/blob/4adb3efaa3ff0e709da91a3d6eb86e0c66a6e3cd/lib/reporter.js#L179
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, is covered now by escapeFileName
lib/fileExportReporter.js
Outdated
await writeSingleFile(exportPath, escapeFileName(file.name), file.content); | ||
} | ||
} catch (err) { | ||
log.warn("An unexpected error occured while exporting files\n\t" + err.message); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we set exit code 1, we should also log this as an error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
lib/fileExportReporter.js
Outdated
if (multiBrowsers) { | ||
exportPath = path.join(exportPath, escapeFileName(browser.name)); | ||
} | ||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try-catch should be around the whole function body (onBrowserComplete). Otherwise errors won't be handled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻
using a window._$files variable; this is no longer read anywhere and such reports are
currently unsupported. See
https://github.com/SAP/openui5/blob/master/src/sap.ui.core/src/sap/ui/core/support/RuleEngineOpaExtension.js#L243
with some additions to browser.js to 'send' the results as part of karma.complete argument
JIRA: CPOUI5FOUNDATION-425