Skip to content
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

Merged

Conversation

gentlementlegen
Copy link
Member

@gentlementlegen gentlementlegen commented Oct 25, 2024

Relates to #138

Description of Changes

This pull request introduces the following changes:

  1. package.json:

    • Corrected formatting in the "exports" section.
    • Added @octokit/plugin-paginate-graphql as a dependency.
  2. src/sdk/actions.ts:

    • Introduced a new constant HEADER_NAME with the value "Ubiquity".
    • Renamed postComment function to postErrorComment for clarity.
    • Enhanced the postComment function logging to accurately reflect posting error comments.
    • Added a new function createStructuredMetadata to format log metadata in a structured manner within the comments posted to GitHub.

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.
@gentlementlegen
Copy link
Member Author

@UbiquityOS can you write the summary of changes made on that pull-request?

Copy link

Summary of Changes in Pull Request #169

This pull request introduces several important updates and improvements to the ubiquity-os/ubiquity-os-kernel project:

  1. package.json Enhancements

    • Formatting Corrections: Improved the formatting in the exports section for better clarity and consistency.
    • New Dependency: Added octokit/plugin-paginate-graphql to the dependencies to enhance GitHub API interactions.
  2. src/sdk/actions.ts Updates

    • New Constant: Introduced a new constant headerName with the value ubiquity to standardize header naming.
    • Function Renaming: Renamed the postComment function to postErrorComment to better reflect its purpose of handling error comments.
    • Enhanced Logging: Improved logging within the postErrorComment function to provide more accurate and detailed information when posting error comments.
    • Structured Metadata Function: Added a new function createStructuredMetadata to format log metadata in a structured manner, ensuring consistency in comments posted to GitHub.
  3. Configuration File Renaming

    • Updated Configurations: Renamed configuration files from .ubiquibot-config.yml to .ubiquity-os.config.yml to align with the new naming conventions.
    • Logger Package Migration: Migrated from @ubiquity-dao/ubiquibot-logger to @ubiquity-dao/ubiquity-os-logger to maintain consistency across the project.
  4. Continuous Integration (CI) Adjustments

    • CI Fixes: Addressed CI failures by migrating the logger package and updating relevant configurations.
    • Ensured CI Stability: Verified that all CI processes pass successfully after the migration, ensuring reliable build and deployment pipelines.
  5. Additional Improvements

    • Issue Linking: Implemented stricter linking of issue numbers (e.g., resolves #1234) to ensure proper association between pull requests and issues.
    • Code Clean-Up: Performed various code clean-ups and optimizations for better maintainability and readability.

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:

@gentlementlegen
Copy link
Member Author

@whilefoo @Keyrxng if you can have a look, can't assign you, thanks!

@gentlementlegen gentlementlegen marked this pull request as ready for review October 25, 2024 03:48
Updated @sinclair/typebox dependency version for compatibility.
Introduce try-catch blocks for schema decoding to handle errors gracefully.
Copy link
Member

@Keyrxng Keyrxng left a 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.

src/sdk/actions.ts Outdated Show resolved Hide resolved
src/sdk/actions.ts Outdated Show resolved Hide resolved
src/sdk/actions.ts Show resolved Hide resolved
src/sdk/actions.ts Outdated Show resolved Hide resolved
src/sdk/actions.ts Outdated Show resolved Hide resolved
src/sdk/actions.ts Outdated Show resolved Hide resolved
@ubiquity-os ubiquity-os deleted a comment from Keyrxng Oct 26, 2024
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.
gentlementlegen and others added 4 commits October 28, 2024 13:01
# 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);
Copy link
Member

@Keyrxng Keyrxng Nov 4, 2024

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

@Keyrxng
Copy link
Member

Keyrxng commented Nov 4, 2024

  1. throw new Error() prints Error twice, not sure if that is something that should be cleaned up
  2. Some string sanitation is affecting the metadata log when throwing new Error
  3. No stack trace in either of them (this is likely a logger issue)

image

  1. Is this how consumers are expected to build plugins now?

image

import { LogReturn } from "@ubiquity-os/ubiquity-os-logger";
import { sanitizeMetadata } from "./util";

const HEADER_NAME = "Ubiquity";
Copy link
Member

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) {
Copy link
Member

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

@Keyrxng
Copy link
Member

Keyrxng commented Nov 4, 2024

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)

Invalid schemas are thrown correctly:
image


if (logMessage?.type === "fatal") {
// if the log message is fatal, then we want to show the metadata
metadataSerialized = [metadataSerializedVisible, metadataSerializedHidden].join("\n");
Copy link
Member

@Keyrxng Keyrxng Nov 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this how it should be displayed? Why don't we just replace <!-- --!> with backticks and show the structured data with the header, is there a reason?

image

image

Copy link
Contributor

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

Copy link
Member

@Keyrxng Keyrxng Nov 4, 2024

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?

Copy link
Contributor

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> ... -->

Copy link
Member

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] ?? "";
Copy link
Member

@Keyrxng Keyrxng Nov 4, 2024

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.

Copy link
Member Author

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.

Copy link
Member

@Keyrxng Keyrxng Nov 5, 2024

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

https://github.com/ubiquity-os-marketplace/command-ask/blame/eb5487d4879e48757ff758ed3fa90728469edcc1/src/handlers/comment-created-callback.ts#L63

Copy link
Member

@Keyrxng Keyrxng Nov 5, 2024

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.
@gentlementlegen
Copy link
Member Author

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 ubiquity-os/plugin-sdk#34.

@Keyrxng
Copy link
Member

Keyrxng commented Nov 5, 2024

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 ubiquity-os/plugin-sdk#34.

Everything handled within the SDK via gentlementlegen#1 so no need to update the logger right now maybe not at all

@gentlementlegen
Copy link
Member Author

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.

@gentlementlegen gentlementlegen merged commit 393ca5d into ubiquity-os:development Nov 6, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants