-
Notifications
You must be signed in to change notification settings - Fork 13
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
Refactor/remove supabase #13
Refactor/remove supabase #13
Conversation
Unused dependencies (1)
Unused exports (2)
Unused types (1)
|
I suppose this is sort of double dipping tasks, perhaps it makes sense to consolidate into a single task #10 |
src/helpers/update-tasks.ts
Outdated
const botComments = comments.filter((o) => o.user?.type === "Bot"); | ||
const dateRegex = /(?<=<td>)(\w{3}, \w{3} \d{1,2}, \d{1,2}:\d{2} (AM|PM) UTC)(?=<\/td>)/gi; | ||
const assignmentRegex = /Ubiquity - Assignment - start -/gi; | ||
const botAssignmentComments = sortAndReturn(botComments.filter((o) => assignmentRegex.test(o?.body || "")), "desc"); | ||
const botFollowup = /this task has been idle for a while. Please provide an update./gi; | ||
const botFollowupComments = botComments.filter((o) => botFollowup.test(o?.body || "")); |
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 it's not a good idea to rely on matching exact text because they might change. It'd be better if we store data in the comment metadata but I'm not sure if we have this functionality implemented.
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 part that was generally available/implemented was the metadata header which could be used as a selector to find the right comment:
I had a generalized function for writing metadata that would add a "comment header" which included the developer defined "metadata class name" and the function caller's name. This was intended to be used as a target for these situations.
https://github.com/ubiquity/ubiquibot/blob/development/src/handlers/shared/structured-metadata.ts#L9
I have successfully written search queries using the GitHub search which leveraged this.
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.
That is what you are seeing here is it not?
const assignmentRegex = /Ubiquity - Assignment - start -/gi;
<!-- Ubiquity - Assignment - start - 86f94c4
{
"duration": 14400,
"priceLabel": {
"id": 7036610424,
"node_id": "LA_kwDOL-In888AAAABo2oneA",
"url": "https://api.github.com/repos/ubiquibot/command-start-stop/labels/Price:%20200%20USD",
"name": "Price: 200 USD",
"color": "1f883d",
"default": false,
"description": null
}
}
-->
ubiquity-os-marketplace/command-start-stop#2 (comment)
It'd be better if we store data in the comment metadata but I'm not sure if we have this functionality implemented.
I forgot to last night but I will add that minor change into one of my open PRs and include the deadline, the userID etc and it can be mapped easier
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 see, this metadata is generated by another plugin, right? Ideally it should be structured like JSON or something similar.
However my point still stands for bot follow-up regex but this can be fixed in a later PR
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 just saw this thread, I had the same concern myself
#13 (comment)
Even by using metadata checking for a string seems unreliable and easily breakable. What is the purpose of checking for this bot comment?
I don't know enough about the problem to say definitively either way. |
I didn't want to mess around with I said to whilefoo that the |
The link doesn't work for me but the file name sounds familiar. Im pretty sure I authored it and it's fine to delete obsolete code.
If it is more reliable then we should switch to this approach. |
I can see that you can filter PRs that have linked issues, but how can you specify that you only want PRs that are linked to a particular issue? |
Thoughts? |
@Keyrxng I also like using the search api because it is powerful and reliable. If it works as expected and gives the same results, it would be great to replace the current code base with it because that wound greatly reduce the code base thus lowering the amount of possible bugs. |
I don't think this will work if the PR was linked via UI, however this already doesn't work with the current approach anyway because even though it relies on events, it still checks the comment. So I guess using search is still a better approach.
|
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 am fine with this, I guess it will be way more performant once we get #15 in.
Resolves #12
May Resolve #10
Env
andadapters
/start
response string literal and the follow up commentcreated_at
ubiquibot-logger
watch: {optIn, optOut}
Which events should be defined in
Supported Events
the same as before and just run the plugin on each or is the wildcard the real event that matters?It would be handy for the
/start
plugin to log the assignee name in the metadata (I'll add in one of my open PRs) and the responses can be mapped to users more reliablytime.ts
is not used in my implementation but if it's preferred/needed I can incorporate it