-
Notifications
You must be signed in to change notification settings - Fork 19
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
feat: improvements #169
feat: improvements #169
Conversation
Introduce postComment function to embed structured metadata in comments.
Added export for Manifest type to facilitate type usage in SDK implementations.
Introduced the paginateGraphQL plugin to enhance API request handling.
@UbiquityOS can you write the summary of changes made on that pull-request? |
Summary of Changes in Pull Request #169 This pull request introduces several important updates and improvements to the
This pull request effectively addresses Issue #138 by implementing these changes, resulting in a more structured, maintainable, and reliable codebase. The updates enhance the project's configuration management, improve logging mechanisms, and ensure seamless integration with GitHub's API and CI pipelines. References: |
Updated @sinclair/typebox dependency version for compatibility.
Introduce try-catch blocks for schema decoding to handle errors gracefully.
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.
A test for this fn would be nice and would resolve my concerns re: new Error
, looks good otherwise.
Consolidated variable initialization and improved error stack handling.
Separated postComment from actions and server files for better modularity.
Ensure proper formatting by adding carriage returns around serialized metadata.
# Conflicts: # src/sdk/server.ts
Change from `payload.settings` to `inputs.settings` for accuracy in error logs.
Changed the comment body in `comment.ts` to use `message.logMessage.diff`.
Deleted revert-pr-108.txt and modified plugin-configuration.ts to permit additional properties.
Validate input schema and log errors if the body is invalid.
Improve readability by storing honoEnv result to a variable before use.
*/ | ||
export async function postComment(context: Context, message: LogReturn) { | ||
if ("issue" in context.payload && context.payload.repository?.owner?.login) { | ||
const metadata = createStructuredMetadata(message.metadata?.name, message); |
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.
message.metadata?.name
will require we update the logger. I implemented pluginName
in this logger PR, is that what name
represents here?
No, name represents className
not pluginName
sorry, I'm confused what className
represents now is it the header by which to parse the structuredMetadata e.g ask-llm-response
import { LogReturn } from "@ubiquity-os/ubiquity-os-logger"; | ||
import { sanitizeMetadata } from "./util"; | ||
|
||
const HEADER_NAME = "Ubiquity"; |
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.
Confused on the purpose of this but if the full header is how we'll search for and parse the structured metadata then we can pull the org via the payload
* Posts a comment on a GitHub issue if the issue exists in the context payload, embedding structured metadata to it. | ||
*/ | ||
export async function postComment(context: Context, message: LogReturn) { | ||
if ("issue" in context.payload && context.payload.repository?.owner?.login) { |
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.
Should we add if("pull_request" in ...)
as well and use pull_request.number
?
I'm not 100% if payloads with "pull_request"
in it always have "issue"
too
I spent like 40mins building complex types to satisfy typebox between the plugin-template and this sdk and turns out typebox versions were not the same lmao, 20 mins to figure out how to use the sdk right. I haven't QA'd the action side of things (don't think that's necessary given the changes) |
|
||
if (logMessage?.type === "fatal") { | ||
// if the log message is fatal, then we want to show the metadata | ||
metadataSerialized = [metadataSerializedVisible, metadataSerializedHidden].join("\n"); |
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.
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.
I think because it allows us to search for the metadata
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.
I thought search would be based on the components of the header not including the HTML comment syntax <!--
at the start of the header. Bit harder to parse I guess without it, my point was duplicating the metadata but it's not a real problem
It's very unlikely we'll ever search by caller
or by revision
I think, what about you guys?
If we used just the headers we could do something like this UbiquityOS - <orgName> - <pluginName>
. First item being the name of the bot, just to make the query a bit more specific. If className
=== LogLevel
then that gives us a type of filter for search if we include it.
Is there a spec for search/parse implementation yet?
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.
when we search we need to search for the comment syntax otherwise it can match other things, so we need to search for <-- UbiquityOS ... <metadata> ... -->
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.
I can't resolve this but think it can be if double metadata being posted is not a problem
const jsonPretty = sanitizeMetadata(metadata); | ||
const stack = logReturn.metadata?.stack; | ||
const stackLine = (Array.isArray(stack) ? stack.join("\n") : stack)?.split("\n")[2] ?? ""; | ||
const caller = stackLine.match(/at (\S+)/)?.[1] ?? ""; |
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.
The QA images I grabbed show that caller is always undefined no matter if it's new Error
or throw logger
You can take caller
from LogReturn
it should already have it and so should Error
too.
Personally I don't see the value in sticking the invoking fn name in the header used for search, but maybe that's short sighted of me.
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.
All of that code was some copy paste of some function you implemented in another project I think, forgot which one, will update that.
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's implemented in command-ask but I only added it last week and took it from this PR. It does look familiar tho I can agree with that, akin to the logger internals I thought at first. Possible I wrote it somewhere else but I can't recall
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's from Ubiquibot V1 actually as far back as that
Replaced ctx.req.json() with body in input decoding to ensure valid input handling.
Since most of the requested changes are about the metadata, we need a PR in the logger to be merged, then the changes will be properly carried out within #180. |
Everything handled within the SDK via gentlementlegen#1 so no need to update the logger right now maybe not at all |
I'll merge this so I can get it deployed on NPM. In the meantime I reviewed your PR @Keyrxng that would solve the related issue. If there is any post merge comment I'll take care of it as well. |
Relates to #138
Description of Changes
This pull request introduces the following changes:
package.json:
@octokit/plugin-paginate-graphql
as a dependency.src/sdk/actions.ts:
HEADER_NAME
with the value "Ubiquity".postComment
function topostErrorComment
for clarity.postComment
function logging to accurately reflect posting error comments.createStructuredMetadata
to format log metadata in a structured manner within the comments posted to GitHub.