-
Notifications
You must be signed in to change notification settings - Fork 6
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
Update description with crash #627
base: master
Are you sure you want to change the base?
Conversation
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.
Looks good!
But I think the intention with #281 was partially also to have the crash report easily visible in the description. Having Arisa add a comment might be useful as well, but it might be a different use case. @misode what do you think?
It might also become spammy when users upload a bunch of crash reports, e.g. "I am not sure which crash report you want so I uploaded all..."
But we can see if that actually becomes a problem.
src/main/kotlin/io/github/mojira/arisa/modules/CrashInfoModule.kt
Outdated
Show resolved
Hide resolved
src/main/kotlin/io/github/mojira/arisa/modules/CrashInfoModule.kt
Outdated
Show resolved
Hide resolved
Main idea from what I understood is being able to search, as jira doesnt search attachments. Comments are less spammy than description too 👀 |
In my opinion having the crash report at the bottom of the description would be better. Comments get pushed away most of the time. But now that I say that, editing descriptions also sounds risky, for example the reporter might be in the middle of editing while the module is triggered. (Although apparently the later user edit would overwrite the crash log, which means this wouldn't be a huge issue) A question I have: what's the point of having a deobfuscated stack trace? |
See #606, mainly:
|
Oh I'm tired. I meant what's the reason for the obfuscated stack trace in the comment? The deobfuscated stack trace should be easier to compare and give you all the information. |
Deobfuscated trace might be wrong
… |
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.
Looks good tech-wise, but I have similar concerns as Misode and Marcono.
I don't think this should be left as a comment. As said in #281 already, I really only think this crash should be integrated into the description when the bug report is initially created.
This is most important if the crash report has been added to the description and the newlines have been messed up. In all other cases it's trivial for a mod or helper to copy stuff from attachments to the description, although it would still be a nice QoL change to not have to open an attachment when checking out a new crash bug report.
Adding a comment every time a crash report is added just causes spam, especially if someone is intentionally uploading unrelated crash reports to a ticket.
src/test/kotlin/io/github/mojira/arisa/modules/CrashModuleTest.kt
Outdated
Show resolved
Hide resolved
src/test/kotlin/io/github/mojira/arisa/modules/CrashInfoModuleTest.kt
Outdated
Show resolved
Hide resolved
src/main/kotlin/io/github/mojira/arisa/modules/CrashInfoModule.kt
Outdated
Show resolved
Hide resolved
Co-authored-by: violine1101 <violine1101@gmail.com>
…Test.kt Co-authored-by: violine1101 <violine1101@gmail.com>
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
@@ -344,6 +344,26 @@ fun addRestrictedComment( | |||
} | |||
} | |||
|
|||
fun addRawComment( |
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 is not needed anymore, is it?
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.
It'd be nice to leave it for future purposes.
newCrashes | ||
.filter { it.second is Crash.Minecraft } | ||
.filterNot { it.first.name.endsWith("deobfuscated.txt") } |
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.
We should probably restrict this to crash reports attached by the reporter (or by a helper / moderator?).
Otherwise users can vandalize existing issues by attaching unrelated crash reports, or files which Arisa considers to be crash reports.
.filter { it.second is Crash.Minecraft } | ||
.filterNot { it.first.name.endsWith("deobfuscated.txt") } | ||
.forEach { | ||
if (!description!!.contains("""\{code.*${it.first.name}]}(\S|\s)*\{code}""".toRegex())) { |
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 (\S|\s)
to match any character including line breaks? Maybe the complete (\S|\s)*\{code}
part can be removed, it is rather unlikely that the description contains {code:title=...}
which is not actually a code block.
Additionally we should probably only add the crash report to the description if it does not contain any (instead of checking for the specific crash report name), to prevent adding multiple crash report snippets. Therefore we should probably only consider newCrashes
if its size is 1, otherwise Arisa might pick the 'wrong' crash report in case a user uploads unrelated ones.
The regex could probably changed to this:
if (!description!!.contains("""\{code.*${it.first.name}]}(\S|\s)*\{code}""".toRegex())) { | |
// Check if description already contains code block which might contain crash report | |
// Note: Jira seems to allow spaces between most of the characters | |
if (!description!!.contains("""\{code:\s*title\s*=.*\[\^.+\.txt\s*]\s*}""".toRegex())) { |
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.
Maybe this regex is too unspecific though and causes some false negatives, e.g. when {code}
blocks link to a non-crash attachment (e.g. code snippet file when a code analysis was done). But I assume that this will happen rarely, so it might be fine for now and we can adjust it later if necessary.
Purpose
Fixes #281
Approach
Future work
Checklist