Improve bug reporting experience and collected info

[nirs]

Description

Our issues sometimes have no details like lima version, os version, or the instance info related to an issue.

Would be useful to add a command collecting all related info, creating an issue, and uploading collected data. Or least collect the data that can be uploaded manually to an issue.

Inspiration: "zed: file bug report" command (Command+Shift+P, type "bug", return). Open a new issue in https://github.com/zed-industries/zed/issues with basic details.

[jandubois]

Yes, I think it would be useful. I don't know if this will work unless the user is already logged into GitHub, but I guess for most users that won't be an issue?

[nirs]

Yes, I think it would be useful. I don't know if this will work unless the user is already logged into GitHub, but I guess for most users that won't be an issue?

If you are not logged, GitHub should log you in and redirect back to the requested URL. Not sure if a tool orchestrating this will have do extra work (cookies etc). But I think the most important thing is collecting the info.

[kairveeehh]

I checked out this issue and thou not completely correct this is the direction I am thinking in , a go cli command that helps log the details for a issue

package main

import (
	"fmt"
	"os"
	"os/exec"
	"time"
)

func main() {
	limaVersion, _ := exec.Command("limactl", "--version").Output()

	osVersion, _ := exec.Command("uname", "-a").Output()


	instanceList, _ := exec.Command("limactl", "list").Output()

	report := fmt.Sprintf(`
### Lima Version
%s

### OS Version
%s

### Instance Info
%s
`, limaVersion, osVersion, instanceList)

	timestamp := time.Now().Format("20060102-150405")
	outputFile := fmt.Sprintf("lima-bug-report-%s.md", timestamp)
	os.WriteFile(outputFile, []byte(report), 0644)

	fmt.Printf("Bug report saved to %s\n", outputFile)
}

could you guide me further on how it needs to be done?

[nirs]

This is a good start, but:

• We need a new limactl command instead of external command, so he user does not have to download another tool, nad the command can access existing code to extract data
• The output should be machine readable so we can process reports automatically. I think yaml format is a good way to make the report both human and machine readable.
• The tool should also collect additional files, so the output should be a director with multiple files. For transferring the data to github issue or sending a report to someone else, we can tar the directory and compress is. This can be done automatically by the tool using the builtin tar package.