push/check modified base rate on base rate change

[gentlementlegen]

A plugin that will update all the price labels if a base rate change is detected. Should most likely be carried out within https://github.com/ubiquibot/assistive-pricing if not already there.

See code reference

[bytegun]

Can I work on this issue?

[jordan-ae]

/start

[ubiquibot[bot]]

Deadline	Mon, May 20, 1:14 PM UTC
Registered Wallet	0x2F05fD58023B0a95d1866aa0A3b672cEf05945c5

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[Keyrxng]

I've already done about 80% of the legwork for this.

The trouble with this @gentlementlegen is that the plugin won't be able to read their org config so cannot process an org wide update.

A repo level update is do-able as it'll be public but I think the spec implies an org-wide label update if the org base rate changes, am I correct in thinking that or did you mean on a per-repo basis?

[jordan-ae]

@Keyrxng Since you've done much of the work already I'll leave it to you then!

[jordan-ae]

/stop

[ubiquibot[bot]]

+ You have been unassigned from the task

[Keyrxng]

@jordan-ae thanks buddy I appreciate it

The repo is private as I've had to consistently log env vars in debugging the situation

[0x4007]

We can consider making the org config public, although to me it seems like a lazy answer. I'm sure that we can solve auth via the app for that repository.

[Keyrxng]

We can consider making the org config public

That would imply that in order to use secrets like keys.openAi it would be strictly through repo secrets, meaning if ever they had to update their API they'd need to update the secret in every repo.

If that is the case, what's the purpose in having properties like keys.openAi in the bot config at all if they are just being pulled from the repo meaning that the kernel won't have access to it just the invoked plugin that requires OPENAI_KEY as a secret.

Maybe I've missed a step in the direction V2 is taking and I need to read over some issues again but I'm a little confused with this

[gentlementlegen]

I am not sure to understand the issue. Each repo should have their own secrets, otherwise we also share secrets on an Org level for things like OPENAI_KEY since it's the same for each repo (only orgs can benefit from these shared secrets).

Problem passing down these through the config or the settings is that it can be vector for abuse by third parties which we want to avoid.

[gentlementlegen]

@Keyrxng something going on here or shall I have a look at it?

[Keyrxng]

No issue I can move on this, ty for the follow up.

EDIT:

It can be done, my setup was wrong. Working on things atm