Cache more #39
Cache more #39
Conversation
|
I'm sad to see the conflict check go, but let's do it if we have to. Maybe @josephperrott's cherry-picking and rebasing bot would be a better place to check for that anyway? |
IgorMinar
left a comment
IgorMinar
left a comment
There was a problem hiding this comment.
I left a comment. One more q:
If the config changes, will we reapply the new rules to all issues and prs? If not then we should - but that should be a separate pr.
| }); | ||
| }); | ||
|
|
||
| exports.deleteCachedConfigs = https.onRequest(async (request: Request, response: Response) => { |
There was a problem hiding this comment.
Why is this fn here? It doesn't seem to be used by anything. It's also missing docs. Can you please explain and document? Thanks
There was a problem hiding this comment.
This will delete the config cached in firebase. It's just in case, if we want to force the bot to do a hard refresh of the config from github (for example if the config changed, but the push event wasn't delivered, then the config in firebase is wrong and we need to force a refresh).
I can clean the firebase database manually, but with this function anyone without access to firebase can also force the refresh (could be useful for caretakers?).
I'll add a comment.
|
If the config changes, we can manually apply the new rules for triage. We could trigger those manual functions from within the config update function if you want. I'd rather keep them separate for now. The status on the other end won't be updated until the next status event (or whatever it is that affect this status). This is because status are linked to commits, not PRs, it would take a LOT of request to update all of them, and I don't have a manual function for that yet. |
Cache the config files for each repo in Firebase instead of requesting them from Github for each PR. Whenever the config is needed, we get it from Firebase, or from Github if we don't have the config in cache (in which case we cache it at the same time). Whenever there is a push commit to master, we check if the config file was updated, and if that's the case we update the cached config. There is also a new get function that you can call to delete all of the cache. This can be used to force a refresh of the cache if the cached config is wrong (if we missed the push event for example).
|
could we add an option to retrigger the status&triage check for a specific
PR/Issue by adding a label (e.g. "bot: re-sync"). The bot would rerun the
rules for the PR or an issue and remove this label once done.
…On Fri, Feb 8, 2019 at 8:39 AM Olivier Combe ***@***.***> wrote:
If the config changes, we can manually apply the new rules for triage. We
could trigger those manual functions from within the config update function
if you want. I'd rather keep them separate for now.
The status on the other end won't be updated until the next status event
(or whatever it is that affect this status). This is because status are
linked to commits, not PRs, it would take a LOT of request to update all of
them, and I don't have a manual function for that yet.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANM6E51QFyBzh4Koja8Foc8F-kxBlpvks5vLagkgaJpZM4aecwu>
.
|
|
We could, but it's already updating status/triage if you add/remove one of the required labels (like |
|
the difference would be that I'd just add a label like "bot: re-sync" and
it would update the issue/pr and delete the label. Today I have to remove
"target" and then add it back, which is two steps and it's annoying.
…On Mon, Feb 11, 2019 at 6:36 AM Olivier Combe ***@***.***> wrote:
We could, but it's already updating status/triage if you add/remove one of
the required labels (like target), I'm not sure if we need to add a
specific option for that.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANM6HvFDmlA3LnL7HCAsZF2a0HL-uPZks5vMX_VgaJpZM4aecwu>
.
|
3 participants
More improvementd to avoid the API rate limit errors:
Total = 1 to 4 requests avoided per event (most of the time 4), which is ~50 to 75% less requests per event for the PRs.