marathon
marathon copied to clipboard
Log files not loading
Gradle 6.7.1 Java 11 Marathon 0.6.2 AGP 4.2.2
I'm having a bit of trouble with the reports. They are not loading into the web page. I suspect that's due to the size, as they seem quite large. It's almost an entire MB for 1 individual test. As such, it's very tough for a web browser to load this large of a text file. It seems like some filtering could be applied to reduce the log file sizes.
Possible duplicate of #355 or #381. Can you start a web-server with the log files and check if that solves the issue?
I'm not sure why that would be helpful. We're running under Jenkins, and basically publishing the report directory to the jenkins server. On that server, the timeline doesn't even render, i assume due to security reasons. Reports that rely heavily on javascript like this are a big issue for publishing to CI servers. I have no control over those servers, so i cannot control what is running and not running on there.
index.html:1 Refused to load the script 'https://momentjs.com/downloads/moment.js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' https://cdn.datatables.net/v/bs4/ https://cdnjs.cloudflare.com/ajax/libs/clipboard.js/ https://cdnjs.cloudflare.com/ajax/libs/highlight.js/ https://cdnjs.cloudflare.com/ajax/libs/remarkable/ https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/ https://code.jquery.com/". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
I also cannot change any of the site security policy, so that's not an option at the moment either.
@Malinskiy
Since you don't have access to your web-server's CSP, the easiest option right now is to download the report files and serve them locally. Another option would be to host a separate HTTP server where you control your CSP fully and serve the reports there, provided you can share the reports storage between your CI (Jenkins) and this new HTTP server.
I get that fully embedded content might not be the most efficient in all cases, but asking users to download the reports and run their own http servers seems like a heavy burden. This is i kind of a non starter for us. Is there a possibility of maybe having an optional way to generate a fully self contained report that will run either in file or dumb server mode? Even if it's a a pretty heavy report in terms of file size, it would be a better option IMHO than creating a separate server.
I'll be happy to review and accept a PR that will generate such a report
@Malinskiy Along with this issue, we are also facing the issue where log files generated are of zero bytes.
Log files might be zero because you don't have anything outputted in the logcat during the tests. Is the issue that you expect something there or that you don't want to see empty files?
Can this be the reason for this.
Exception in thread "LogCatLogger-emulator-5554" java.lang.NoSuchMethodError: 'com.android.ddmlib.logcat.LogCatTimestamp com.android.ddmlib.logcat.LogCatMessage.getTimestamp()'
at com.malinskiy.marathon.android.ddmlib.DdmlibAndroidDevice$listener$1.invoke(DdmlibAndroidDevice.kt:75)
at com.malinskiy.marathon.android.ddmlib.DdmlibAndroidDevice$listener$1.invoke(DdmlibAndroidDevice.kt:48)
at com.malinskiy.marathon.android.ddmlib.DdmlibAndroidDevice$sam$com_android_ddmlib_logcat_LogCatListener$0.log(DdmlibAndroidDevice.kt)
at com.android.ddmlib.logcat.LogCatReceiverTask.notifyListeners(LogCatReceiverTask.java:128)
at com.android.ddmlib.logcat.LogCatReceiverTask.access$300(LogCatReceiverTask.java:35)
at com.android.ddmlib.logcat.LogCatReceiverTask$LogCatOutputReceiver.processLogLines(LogCatReceiverTask.java:113)
at com.android.ddmlib.logcat.LogCatReceiverTask$LogCatOutputReceiver.processNewLines(LogCatReceiverTask.java:106)
at com.android.ddmlib.MultiLineReceiver.addOutput(MultiLineReceiver.java:104)
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:706)
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:760)
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:511)
at com.android.ddmlib.internal.DeviceImpl.executeShellCommand(DeviceImpl.java:691)
at com.android.ddmlib.logcat.LogCatReceiverTask.run(LogCatReceiverTask.java:74)
at com.malinskiy.marathon.android.ddmlib.DdmlibAndroidDevice$logcatThread$1.invoke(DdmlibAndroidDevice.kt:67)
at com.malinskiy.marathon.android.ddmlib.DdmlibAndroidDevice$logcatThread$1.invoke(DdmlibAndroidDevice.kt:48)
at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)
Yes, this is an indication that your classpath contains an incompatible (from an API standpoint) version of ddmlib. Possible ways to solve this include changing the classpath in your build or switching to the CLI version of marathon
@Malinskiy : Log files are still not loading for us in both local (when we start a http server via python) as well as CI. On further investigating this with our CI team, we found that the actual log file report name and the log file name that comes out of the request we make on clicking "Log File" link in html report are not same. Here is an example for same: Actual logfile name: TestClassRelativePath.TestClassName#TestName-8c332e34-d147-4640-8097-16b18810057f.log Logfile name from http request via "Log File" link: TestClassRelativePath.TestClassName%23TestName.log
Do you know why there is this ID -8c332e34-d147-4640-8097-16b18810057f at the end of actual log file name?
When we renamed the actual log file such that we remove the above ID, it loads the log file successfully in both local and CI.
Removing the IDs from actual log file names should fix the issue. Please let us know if a quick fix can be pushed for this as we are blocked on this last issue before we start using Marathon in our project.
@pavanagarwal this issue is solved in #536. will be released in 0.6.3. you can use a snapshot version of marathon from develop for now. To build the latest yourself execute ./gradlew :cli:assembleDist
, output is in the cli/build/distributions/marathon-*-SNAPSHOT.zip
Closing since the fix was deployed a long time ago Please reopen if the problem appears again.