GitHub Issue Summarizer using Modus & GitHub Actions

[StephDietz]

• When an issue is closed, a GitHub Action triggers the Modus function.
• The function fetches the issue details and comments using the GitHub API.
• A KB article is generated using the issue details and the Meta-Llama-3.1 model.
• The article is then posted as a GitHub Discussion for easy reference.

[mattjohnsonpint]

May want to mention that for this example you'll need Go and TinyGo installed also.

[mattjohnsonpint]

The leading whitespace on each line of the prompt will be passed to the model, which may (or may not) decide to give the same whitespace in the markdown result. It would be best to not indent any of these lines. Unindent them all the way to the left.

[mattjohnsonpint]

Test the temperature setting. If it's not affecting the result, remove it and stick with the default.

[mattjohnsonpint]

Here and throughout, fmt.Printf is being used to report errors. The problem with that is the calling function will still see it as success. Only the local logs will show the message, and just as non-categorized information.

A better approach for errors is to return an error, and then check that error in the calling function, and/or return it all the way up to the exported Modus function.

Suggested change

	fmt.Printf("Error fetching issue details: %v\n", err)
	return
	return fmt.Errorf("error fetching issue details: %w", err)

Notes:

• Start errors with lower case letters
• Don't include a \n
• Use %w instead of %v when wrapping an existing error object.
• If there's no existing error but you're just creating a string error message, then use errors.New instead of fmt.Errorf

In the case of success logging, you can continue to use fmt.Println if it's indeed a single line. Alternatively you could use the Modus console API, and use console.Info so it has reports with INF level instead of ???.

If you're logging debug details, use console.Debug so it gets DBG status, and more importantly, if there's possibly more than one line of output, then you must use one of the console functions so the lines are kept together in a single message. (fmt.Println and similar just write to stdout or stderr, so every line is treated as a separate logging message by the Modus runtime.)

[matthewmcneely]

You may want to mention that this is a repository in which you want to run the summarizer.

[matthewmcneely]

At this stage the viewer is in their cloned repo right, how to they get the required files (main.go, modus.json, etc) into this folder? Maybe I'm missing something.

[matthewmcneely]

Is 1.23.6 really required? For instance, I'm running 1.23.3 and was able to get it to build (once I fixed the token parameter issue).

[mattjohnsonpint]

"required" is an interesting word. There are security vulnerabilities in 1.23.5 that were fixed in 1.23.6.
Go 1.23.1 had security fixes (so 1.23.0 is out). Go 1.23.2 - .5 did not, but then .6 did, so now .6 is "required".

Also, we have Trunk in this repo, which uses OSV-Scanner, and will hit on some vulnerabilities depending on Go version. I've put some manually into the ignore list, but they're only false positives if you're actually running 1.23.6. Otherwise they could indeed be hit. (well, not the ppc one, but perhaps the others depending on the code.)

In general, we recommend apps target the latest version of Go to avoid worrying about such things. Since this is a "recipes" repo then yes - our recommendations should be applied.

[matthewmcneely]

Totally get it from a production software sense--but my point was that this would stop a significant number of people from completing the recipe if it meant they had to upgrade Go on their system.

[matthewmcneely]

When I modus dev from the new folder in your branch, the handler runs on 8686. Don't see anywhere where this is configured for 54321.