Task matching

[sshivaditya2019]

Resolves #7

• Adds a issue matching option.
• Works on issue.labeled, issues.created and issues.edited.
• Updates the payload object, when someone is assigned a particular issue.

[sshivaditya2019]

Example issue:

New Issue
Old Issue

Should it search for only closed issues ? Or Should i check in progress issues as well ?

So, for the closed as complete, we would have to listen to issues.closed webhook, or should we use the linked PR to check if it was closed as complete?

[0x4007]

Updates the payload object, when someone is assigned a particular issue.

I don't understand what you mean by this.

Should it search for only closed issues ? Or Should i check in progress issues as well ?

Only closed as completed issues. This proves that they were able to accomplish the task.

So, for the closed as complete, we would have to listen to issues.closed webhook, or should we use the linked PR to check if it was closed as complete?

I don't understand. No webhooks are applicable here. You use GraphQL to search all the "closed as complete" issues that are assigned to the contributor.

[sshivaditya2019]

Updates the payload object, when someone is assigned a particular issue.

I don't understand what you mean by this.

If some is assigned an issue that particular issue's payload is updated. This could be rewritten with graphql instead.

Should it search for only closed issues ? Or Should i check in progress issues as well ?

Only closed as completed issues. This proves that they were able to accomplish the task.

So, for the closed as complete, we would have to listen to issues.closed webhook, or should we use the linked PR to check if it was closed as complete?

I don't understand. No webhooks are applicable here. You use GraphQL to search all the "closed as complete" issues that are assigned to the contributor.

Shouldn't it be a query with similar issues and who completed them. Instead of querying with all users.

So, when issues are completed their payload object will still show as open. To prevent this we could listen for webhooks.

[0x4007]

I'm sorry but I have little context on the "payload object" I haven't worked on any plugins officially. Feel free to ask me clarifications on the spec.

Perhaps @gentlementlegen might know what you're talking about

[sshivaditya2019]

Fixed, Now, its using graphQL for query, listens only for issues.labled, issues.opened and issues.edited. For QA

New Issue
Old Issue

[0x4007]

Fixed, Now, its using graphQL for query, listens only for issues.labled, issues.opened and issues.edited. For QA

New Issue Old Issue

QA looking good. Please check my comment under "old issue" regarding formatting! Once thats in I would like to merge.

[sshivaditya2019]

Updated the comment structure, the comments should start with >[!NOTE] , followed by the ">The following contributors may be suitable for this task:", and then match percentage

[0x4007]

Did you test this? The syntax doesn't look correct. Pretty sure all quotes need the space to avoid problems

[sshivaditya2019]

Did you test this? The syntax doesn't look correct. Pretty sure all quotes need the space to avoid problems

Its working, you can check the updated comment in the (Old Issue)

[0x4007]

@gentlementlegen can you install this plugin

[gentlementlegen]

@0x4007 Is this plugin supposed to be a worker or an action? According to the readme it should be an action but no deployment script has been added here.

---

Since I was not sure in the meantime I set it as an Actions and I fixed the run crashing here.

[sshivaditya2019]

run crashing

It should be deployed as an worker, but it does work as an action as well.

[gentlementlegen]

Added deployment scripts, last run here, will change to a worker in the configuration. Also fixed default values for the configuration and modified the description in the manifest to remove a reference to ubiquibot.

[gentlementlegen]

Another question, I am confused by these logs. Does it mean it is running properly?

---

Error PGRST204 seems to indicate that a column is missing, so my guess is that it is not pointing to the right database, will have a look.

[gentlementlegen]

@0x4007 I do not see a database set up on Supabase for this. Could you create an instance? I do not have the permissions to do so.

[0x4007]

You can make a separate database. We can clean house another week

[gentlementlegen]

You mean that I should use my own credentials / API keys for this db?

[gentlementlegen]

I upgraded with my own credentials. Heads up that now it seems you're limited to two projects on Supabase.

[0x4007]

I think just make one ubiquity-os project on your Supabase and then make new tables with the names of the plugins I guess.

[gentlementlegen]

This would need a centralized migration file to keep the db up to date. Projects with dbs already have their own migration files so all projects should be merged.

[0x4007]

I prefer figuring out git based storage as a "final" storage solution. Let's make do in a janky way with Supabase for the short term.

It would be extremely convenient if the plugin repositories themselves can handle everything: runtime/hosting (GitHub actions) and storage.

Maybe some day in the future we can optimize the cold start times (i.e. compile to something that runs natively without node) to use GitHub actions in place of workers.

[gentlementlegen]

If there is an efficient way to store, access, sort and join millions of items based on a git system, this can be replaced. Vector embeddings should have a consequent size quickly. I think in the meantime each project should use their own db when possible.

---

The project seems properly set up although it always fails to create entries, see this run. @sshivaditya2019 Am I doing something wrong?

[sshivaditya2019]

If there is an efficient way to store, access, sort and join millions of items based on a git system, this can be replaced. Vector embeddings should have a consequent size quickly. I think in the meantime each project should use their own db when possible.

The project seems properly set up although it always fails to create entries, see this run. @sshivaditya2019 Am I doing something wrong?

The issue_id acts as the foreign key, which requires the related issue to be present in the database before creating the comment. However, if the issue_id is missing, we could provide a Null value instead. But that would render the issues table unnecessary.

[gentlementlegen]

So how is an issue created?

[sshivaditya2019]

So how is an issue created?

Currently, the expected process is as follows:

An issue is created, followed by comments that can be created, edited, or deleted. When an issue is deleted, all associated comments are also removed.

[gentlementlegen]

Okay it does work when an issue is created, I do get new entries in the issue_comments table. Is plaintext always supposed to be NULL?

[sshivaditya2019]

Its something do with the it being run in GitHub actions. plaintext is not supposed to null, so is payload.

[gentlementlegen]

@sshivaditya2019 It is currently running within Workers since I know it runs properly now, so I don't think that is the reason.

[sshivaditya2019]

I am trying to deploy it on worker right now with the workers script. In the meantime could you please try https://ubiquity-os-comment-vector-embeddings.sshivaditya.workers.dev this. I can check if issues are begin created here or not.

[sshivaditya2019]

Okay it does work when an issue is created, I do get new entries in the issue_comments table. Is plaintext always supposed to be NULL?

Is this a private repository ? If yes, then its expected behavior.

[gentlementlegen]

@sshivaditya2019 It is a private repository indeed, I forgot about the redacting of the comments, it makes sense now. I will try with a public repo.

[0x4007]

Maybe we shouldn't redact comments in the near future. And instead have a switch for it later when/if partners ever ask. I feel like most people won't care and it will give us more data to work with for research purposes in the near future.

[0x4007]

@sshivaditya2019 do you think we should make a new task to create a script to populate our database with the issues? We have a ton of old data we can benefit from.

[gentlementlegen]

Maybe we shouldn't redact comments in the near future. And instead have a switch for it later when/if partners ever ask. I feel like most people won't care and it will give us more data to work with for research purposes in the near future.

I guess it would be fine to have it as an option in the configuration, because as long as not everybody can access the DB the content of private repositories cannot be read by outsiders.

[sshivaditya2019]

@sshivaditya2019 do you think we should make a new task to create a script to populate our database with the issues? We have a ton of old data we can benefit from.

Are we taking about something like a seed file ? That should be easy. Otherwise, I can probably write a python/js script to do that. Either way it would be better to have a separate task/ticket to handle that.

[sshivaditya2019]

Maybe we shouldn't redact comments in the near future. And instead have a switch for it later when/if partners ever ask. I feel like most people won't care and it will give us more data to work with for research purposes in the near future.

I guess it would be fine to have it as an option in the configuration, because as long as not everybody can access the DB the content of private repositories cannot be read by outsiders.

Issue is that, if by chance the key gets leaked, and orgs private issue threads are leaked as well, it would an serious issue for the plugin maker (Ubiquity) in this case.