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/teams #11

Merged
merged 18 commits into from
Aug 20, 2024
Merged

Conversation

Keyrxng
Copy link
Contributor

@Keyrxng Keyrxng commented Jul 15, 2024

Resolves #6
Requires #10

QA: ubq-testing#2 (comment)

Copy link

Unused files (2)

src/main.ts, src/plugin.ts

Unused dependencies (2)

Filename dependencies
package.json @actions/core
@actions/github

Unused exports (1)

Filename exports
src/types/plugin-input.ts startStopSettingsValidator

Unused types (1)

Filename types
src/types/plugin-input.ts PluginInputs

@Keyrxng
Copy link
Contributor Author

Keyrxng commented Jul 15, 2024

@0x4007 Should I impose maxConcurrentTasks checks on all teammates or just the command invoker?

@0x4007
Copy link
Member

0x4007 commented Jul 15, 2024

@0x4007 Should I impose maxConcurrentTasks checks on all teammates or just the command invoker?

I don't really understand the full context of the question. I think in the future this makes more sense to discuss under the issue specification instead.

maxConcurrentTasks is a setting that allows us to let some users only work on up to a certain amount of tasks at any given time.

Core team members should have higher limits compared to external people.

The check only happens upon task assignment /start

@Keyrxng
Copy link
Contributor Author

Keyrxng commented Jul 15, 2024

given that this PR adds extends /start to allow assigning more than one person, should those checks be done against only the command invoker or should we check each user in the command string?

If done only against the invoker users could get around these checks but doing it against all might limit collaboration.

Currently the check is performed against the command invoker only

@0x4007
Copy link
Member

0x4007 commented Jul 15, 2024

Currently the check is performed against the command invoker only

check each user

Checking each user seems correct based on the vision.

src/handlers/shared/start.ts Outdated Show resolved Hide resolved
src/handlers/shared/start.ts Show resolved Hide resolved
@Keyrxng
Copy link
Contributor Author

Keyrxng commented Aug 6, 2024

QA: ubq-testing/bot-ai#27 (comment)

There seems to be a bug that I cannot seem to resolve. In the QA issue no problems, it's a public repo and public tasks. I also have a private issue in my ubiquibot-config repo and for some reason it just will not let me assign two users at once.

I can self assign as keyrxng2 but I cannot dual-assign from either account. I am logging the assignees and both are being passed, nothing is different logic wise just the repo/issue env.

image

I am passing the array to the octokit.addAssignees() and when I use a for-of loop I get this rapid assigning/unassigning
image


Have you folks encountered anything like this before? I think it's actually a feature of GitHub because I cannot dual-assign via the UI either...

Should I account for this and detect if it's a private repo and comment a custom message?

@whilefoo
Copy link

whilefoo commented Aug 6, 2024

I can self assign as keyrxng2 but I cannot dual-assign from either account

I'm not completely sure but I think that's because for private repos you need Github subscription to have that option

@Keyrxng
Copy link
Contributor Author

Keyrxng commented Aug 6, 2024

I can self assign as keyrxng2 but I cannot dual-assign from either account

I'm not completely sure but I think that's because for private repos you need Github subscription to have that option

https://github.com/orgs/community/discussions/7150

Seems you are correct @whilefoo. We'd need permissions to access billing to determine this I'm sure so if we are to implement some sort of custom message then would we do it by simply checking assignees.length after assigning?

Or no custom message and deal with it if we need to later?

src/utils/issue.ts Outdated Show resolved Hide resolved
src/utils/issue.ts Outdated Show resolved Hide resolved
src/utils/issue.ts Outdated Show resolved Hide resolved
@whilefoo
Copy link

whilefoo commented Aug 6, 2024

Or no custom message and deal with it if we need to later?

I think it's fine without the messages (most orgs will have paid plans)

@0x4007
Copy link
Member

0x4007 commented Aug 6, 2024

Or no custom message and deal with it if we need to later?

I think it's fine without the messages (most orgs will have paid plans)

If this isn't a lot of work I think just include the custom error message within this pull? Seems to me like this can be handled in a few lines of code.

src/utils/issue.ts Outdated Show resolved Hide resolved
src/utils/issue.ts Outdated Show resolved Hide resolved
tests/main.test.ts Outdated Show resolved Hide resolved
src/plugin.ts Outdated Show resolved Hide resolved
src/plugin.ts Outdated Show resolved Hide resolved
Copy link
Member

@gentlementlegen gentlementlegen left a comment

Choose a reason for hiding this comment

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

Good to go for me when you addressed the remaining comments.

@Keyrxng Keyrxng merged commit ac245ff into ubiquity-os-marketplace:development Aug 20, 2024
2 checks passed
@ubiquity-os ubiquity-os bot mentioned this pull request Aug 20, 2024
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.

Teams /start @user
4 participants