feat: global label change via config

[Keyrxng]

Resolves https://github.com/ubiquibot/plugins-wishlist/issues/8

• adds a new config item globalConfigUpdate which contains enable: boolean, excludeRepos:[""]
• I was able to re-use syncPriceLabelsToConfig() but it meant moving the typeguard check into the eventName switch case and out of the function
• I had to fix eslint and ts errors which is why there are small changes across seemingly unrelated files
• renamed setPrice to getPrice
• removed logger.fatal() calls
• salvaged most of the tests from my plugin

---

excludeRepos will have many uses but the reason that spurred me to include it was that in my QA devpool-directory was being updated with a green Price: $10 label when it should have a grey Pricing: $10 so that would likely be a default for us to include

[gentlementlegen]

@Keyrxng Can you please resolve the conflicts?

[Keyrxng]

QA: https://github.com/ubq-testing/assistive-pricing/actions/runs/11088257095/job/30807939009

I use the worker for local testing but this is now an action plugin after this PR.

Auth:

Pre: 3x

Post: 3x

Pre: 10x

Post: 10x

---

The logic right now is like this:

1. with globalConfigUpdate omitted, we simply update the repo labels and we do not update or remove labels from tasks.
2. enabled, we delete any incorrect price label from issues according to the new reward bracket and then update all issues with time and priority labels with new pricing.

About number one, with it omitted, should this feature update currently priced tasks to the new bracket?

About two, should all time and priority labeled tasks have a price label applied to them? Or should they remain unpriced if they were unpriced before the run?

[gentlementlegen]

@Keyrxng I tested in my org and it seems to work fine, I have a few questions however:

• you mentioned that it should be an Action, but this is currently a Worker, so how do we set this up?
• running it on my whole org took ~10 minutes, speed is not really a factor but the problem was that plenty of issues remained unlabeled for the whole duration since it does the update step by step. Couldn't we parallelize this more to get it running faster?

[Keyrxng]

Couldn't we parallelize this more to get it running faster?

Can it be addressed in another task because it'll take some time to work out how best exactly to optimize for speed while trying to avoid both this plugin hitting the secondary and also allowing enough room for other plugins that are operating on the same token to operate effectively.

you mentioned that it should be an Action, but this is currently a Worker, so how do we set this up?

It uses the same env vars so just update the - plugin: <url> to point at the repo instead.

[gentlementlegen]

Can it be addressed in another task because it'll take some time to work out how best exactly to optimize for speed while trying to avoid both this plugin hitting the secondary and also allowing enough room for other plugins that are operating on the same token to operate effectively.

Sure thing.

It uses the same env vars so just update the - plugin: to point at the repo instead.

What about the commands and the change of labels that have to respond instantly?

[Keyrxng]

What about the commands and the change of labels that have to respond instantly?

You want to split this like telegram-bridge then and have workflow and worker proxy callbacks and we can have the best of both worlds? There's no way we can optimize things enough that we can run a global update like this on one worker request, I don't see that happening, although I haven't tried it deployed but very unlikely.

[gentlementlegen]

If it is no deal breaker that /allow and label changes take long to respond then no I do not mind, @0x4007 @whilefoo what do you think?

[gentlementlegen]

@Keyrxng Can you resolve the conflicts thank you.

[0x4007]

If it is no deal breaker that /allow and label changes take long to respond then no I do not mind, @0x4007 @whilefoo what do you think?

I already have a solution in the works for ~3 second typescript GitHub action, cold start response time, so I don't think the lag will be an issue in the near future.