Issue Reporter: Support configuring data sent to extensions #46726
Comments
|
By default the extension log should definitley be included within the report. Extension settings would also be very helpful. |
|
To add to what @RMacfarlane says, the PowerShell extension would love to supply the Here is an example of the PowerShell version info and extension info we generate with our extension's bug report command: PowerShell Information
Visual Studio Code ExtensionsVisual Studio Code Extensions(Click to Expand)
If we had this and there was a way to invoke the issue reporter programmatically, we would redirect bug report command to pop the issue reporter and probably, over time phase out our bug report command in favor of the built-in one. |
|
Oh and we'd like to show them how to attach log files generated by the extension to the bug report e.g.: Attached LogsFollow the instructions in the README about capturing and sending logs. Of course, if the issue reporter supported attachment of log files (or zip of log files) and uploaded that with the bug report - that'd be sweet!! |
Yes! But we would only need the non-default settings. |
|
The Docker extension along with several Azure extensions managed by @EricJizbaMSFT and @StephenWeatherford would really benefit from this as well. |
|
I'm thinking the best API for this kind of thing is a typical provider model: interface IssueDataProvider {
provideIssueData(): ProviderResult<string | MarkdownString>;
}
namespace env {
export function registerIssueDataProvider(provider: IssueDataProvider): Disposable;
}Reusing Also since |
|
Do you plan to make the Issue Reporter dialog give the user a preview of the data the extension wants to send? And/or an option to exclude it? When logged in at GitHub we only get to see issue contents after filing. |
Yes. Similar to when you open an issue on VS Code and it shows you the additional data that will be included in your issue... except probably more obvious since it's coming from a random extension instead of VS Code.
You have the ability to see all of it, today via the different "show more"s, just not in one big text area like you do on GitHub. I do want to have a preview button and that's #117657 We did it the way that we did because there's a hard limit on number of characters that a browser can handle via a query parameter so if you're logged in we can simply use a POST to the issue API which will guarantee it's creation. Not the best experience but better than asking the user to paste content in. |
|
Would some sort of state object be suitable, e.g., programmatically execute the "Report Issue..." command, with an object containing state that is subsequently passed into As an example, in the Docker and most Azure extensions we trap errors and, in some cases, show an error toast with a "Report issue" button, that opens the issue reporter with the extension pre-selected. It would be helpful to be able to pass along that error into the |
|
Yeah that's a good idea. I know we already have a command for launching the issue reporter with pre-filled data. I think it can probably be a bit more ergonomic. |
|
Some interesting data on how some extensions have implemented their own
For the remote extensions that open the issue reporter completely blank I believe it was a bug that I fixed a few days ago... they now should open with their extension pre-selected. |
|
Here's an iterative (hacked up) mockup of what the Issue Reporter could look like with the extension contributed data: words can change but the idea is that we widen the issue reporter to make way for a 2nd column being the data that the extension provides. The current API proposal aligns with this model. The interface OpenIssueReporterArgs {
readonly extensionId?: string;
readonly issueTitle?: string;
readonly issueBody?: string;
}would include an additional Now I think these needs 2 additional things:
|
|
That makes sense. For us, what we ultimately need is to be able to put data into the issue body--metadata like call stack, error, OS, extension-specific info, etc.--while still requiring users to type something as well. We receive a considerable volume of issues where the user enters something into the title, but nothing in the details or repro steps, usually resulting in unactionable issues. |
|
Is there any way to make the data like the "Include" options that come baked in? Basically be checkboxes with the "show" link to show what's being included? I'm wondering if that might help make all the data less ominous to users? And I do appreciate manually sending in the template if you go the GitHub issues direction as we purposefully turn off the ability to open a new issue to direct users through our "Report Issue" command 😁. Lastly, other than some select settings outside of what our extension provides, we include every setting that is set to a non-default value. We also anonymize any setting that is free-form in case there's PII, but otherwise include any setting the user specified. Not sure if it would make sense to do that automatically since the setting contributions are known to Python and the type details for those settings are also known. |
I opted against this with the concern that since we don't own every extension in the marketplace, we can't be sure that their data capturing processes are up to par. So I aired on the side of caution and made the extension issue data front and center. I understand that this might increase the likelihood of an empty issue (the user just deletes the content) but I think that this cohort of "security cautious but not willing to scan data manually" is small compared to others.
I think this is a good idea but it would make a good addition to this proposal rather than a replacement. I think there is still a need for data only available at runtime. |
|
Excited about the proposal! @TylerLeonhardt I have a github issue form for remote-ssh bugs which I would also love to port over to this new issue reporter. From what I can see, everything you have planned fits with the features I have for my issue form. The first comment I have is I am not sure if this is already planned but I have really appreciated having long items in dropdowns (this is done on the python report issue command so I assume that is done everywhere) but just wanted to bring it up as it does help keep issues visually cleaner even when we are gathering extensive logs. Secondly, will the issue reporter allow assigning tags or assignees? Since remote-ssh has all bug reports go through the remote-release repo I have my bug report form assigning it to me and adding "ssh" as a label for organizational purposes. |
yeah we would collapse it in a dropdown on the issue for sure.
Users who aren't in the GH Org can't assign people or add tags so this doesn't seem useful to support. Instead, you could use an Issue Form Template which allows for a hardcoded list of assignees & labels. |
|
Hello! Is this already available through the VS Code API? I am not very familiar on how new APIs get merged, but I wanted to use this new capability in our own extension, so I was wondering what should I need to do in order to have access to this new API: if someone has a working example of a customized issue reporter, that would be very useful! Regards, |
|
this is available ATM! extensions can contribute a command which will be triggered in the reporter when selecting their extension as long as they follow this menu contribution point: "commands": [
{
"command": "extension.myCommand",
"title": "Report Issue"
}
],
"menus": {
"issue/reporter": [
{
"command": "extension.myCommand"
}
]
}
check out https://code.visualstudio.com/updates/v1_87#_contributing-additional-data-in-issue-reporter for additional details. here is also our internal testing item which has some additional instructions #203094 please let me know what you guys think! |
Continuation of #45673
Now that users can choose to file on extensions, extension authors should be able to specify additional data to include in the report. This could potentially include
launch.jsoninformationThe text was updated successfully, but these errors were encountered: