NextERP/runbot
5
0
Fork 0
mirror of https://github.com/odoo/runbot.git synced 2025-03-17 00:15:47 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
16.0-fix-views-xdo
runbot/runbot_merge/data/merge_cron.xml

73 lines
3.1 KiB
XML
Raw Permalink Normal View History

[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
<odoo>
<record model="ir.cron" id="merge_cron">
[IMP] runbot_merge: split staging cron in two The staging cron was already essentially split between "check if one of the stagings is successful (and merge it)" and "check if we should create a staging" as these were two separate loops in the cron. But it might be useful to disable these two operations separately e.g. we might want to stop the creation of new staging but let the existing stagings complete. The actual splitting is easy but it turns out a bunch of tests were "optimised" to only run the merge cron. Most of them didn't blow up but it seems more prudent to fix them all. fixes odoo/runbot#310
2020-02-07 17:52:42 +07:00
<field name="name">Check for progress of (and merge) stagings</field>
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
<field name="model_id" ref="model_runbot_merge_project"/>
<field name="state">code</field>
[IMP] runbot_merge: split staging cron in two The staging cron was already essentially split between "check if one of the stagings is successful (and merge it)" and "check if we should create a staging" as these were two separate loops in the cron. But it might be useful to disable these two operations separately e.g. we might want to stop the creation of new staging but let the existing stagings complete. The actual splitting is easy but it turns out a bunch of tests were "optimised" to only run the merge cron. Most of them didn't blow up but it seems more prudent to fix them all. fixes odoo/runbot#310
2020-02-07 17:52:42 +07:00
<field name="code">model._check_stagings(True)</field>
<field name="interval_number">1</field>
<field name="interval_type">minutes</field>
<field name="numbercall">-1</field>
<field name="doall" eval="False"/>
</record>
<record model="ir.cron" id="staging_cron">
<field name="name">Check for progress of PRs and create Stagings</field>
<field name="model_id" ref="model_runbot_merge_project"/>
<field name="state">code</field>
<field name="code">model._create_stagings(True)</field>
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
<field name="interval_number">1</field>
<field name="interval_type">minutes</field>
<field name="numbercall">-1</field>
<field name="doall" eval="False"/>
</record>
[IMP] runbot_merge: split tagging cron out of main progress cron They're completely independent (or should be), and there's no reason for the tagging cron to extend the "lifetime" of the main cron's transaction (and thus extend the odds of racey behaviour).
2018-10-12 20:54:14 +07:00
<record model="ir.cron" id="feedback_cron">
<field name="name">Send feedback to PR</field>
[IMP] runbot_merge: small reorg of main models file To prep for the addition of the freeze wizard: * move projects out of `pull_requests.py` * then realize half the methods there have no relation to projects and move them to more relevant places in `pull_requests.py` * update corresponding crons (and tests using those crons) as the methods have changed model, and the cron definitions thus need to be updated * split update to labels out of sending feedback comments while at it: labels are not used much during tests so their manipulation can be avoided; and labels are not as urgent as feedback so the crons can be quite a bit slower * move the project view out of `mergebot.xml` as well
2021-11-10 19:13:34 +07:00
<field name="model_id" ref="model_runbot_merge_pull_requests_feedback"/>
[IMP] runbot_merge: split tagging cron out of main progress cron They're completely independent (or should be), and there's no reason for the tagging cron to extend the "lifetime" of the main cron's transaction (and thus extend the odds of racey behaviour).
2018-10-12 20:54:14 +07:00
<field name="state">code</field>
[IMP] runbot_merge: small reorg of main models file To prep for the addition of the freeze wizard: * move projects out of `pull_requests.py` * then realize half the methods there have no relation to projects and move them to more relevant places in `pull_requests.py` * update corresponding crons (and tests using those crons) as the methods have changed model, and the cron definitions thus need to be updated * split update to labels out of sending feedback comments while at it: labels are not used much during tests so their manipulation can be avoided; and labels are not as urgent as feedback so the crons can be quite a bit slower * move the project view out of `mergebot.xml` as well
2021-11-10 19:13:34 +07:00
<field name="code">model._send()</field>
[IMP] runbot_merge: split tagging cron out of main progress cron They're completely independent (or should be), and there's no reason for the tagging cron to extend the "lifetime" of the main cron's transaction (and thus extend the odds of racey behaviour).
2018-10-12 20:54:14 +07:00
<field name="interval_number">1</field>
<field name="interval_type">minutes</field>
<field name="numbercall">-1</field>
<field name="doall" eval="False"/>
</record>
[IMP] runbot_merge: small reorg of main models file To prep for the addition of the freeze wizard: * move projects out of `pull_requests.py` * then realize half the methods there have no relation to projects and move them to more relevant places in `pull_requests.py` * update corresponding crons (and tests using those crons) as the methods have changed model, and the cron definitions thus need to be updated * split update to labels out of sending feedback comments while at it: labels are not used much during tests so their manipulation can be avoided; and labels are not as urgent as feedback so the crons can be quite a bit slower * move the project view out of `mergebot.xml` as well
2021-11-10 19:13:34 +07:00
<record model="ir.cron" id="labels_cron">
<field name="name">Update labels on PR</field>
<field name="model_id" ref="model_runbot_merge_pull_requests_tagging"/>
<field name="state">code</field>
<field name="code">model._send()</field>
<field name="interval_number">10</field>
<field name="interval_type">minutes</field>
<field name="numbercall">-1</field>
<field name="doall" eval="False"/>
</record>
[IMP] runbot_merge: split tagging cron out of main progress cron They're completely independent (or should be), and there's no reason for the tagging cron to extend the "lifetime" of the main cron's transaction (and thus extend the odds of racey behaviour).
2018-10-12 20:54:14 +07:00
<record model="ir.cron" id="fetch_prs_cron">
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
<field name="name">Check for PRs to fetch</field>
[IMP] runbot_merge: small reorg of main models file To prep for the addition of the freeze wizard: * move projects out of `pull_requests.py` * then realize half the methods there have no relation to projects and move them to more relevant places in `pull_requests.py` * update corresponding crons (and tests using those crons) as the methods have changed model, and the cron definitions thus need to be updated * split update to labels out of sending feedback comments while at it: labels are not used much during tests so their manipulation can be avoided; and labels are not as urgent as feedback so the crons can be quite a bit slower * move the project view out of `mergebot.xml` as well
2021-11-10 19:13:34 +07:00
<field name="model_id" ref="model_runbot_merge_fetch_job"/>
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
<field name="state">code</field>
[IMP] runbot_merge: small reorg of main models file To prep for the addition of the freeze wizard: * move projects out of `pull_requests.py` * then realize half the methods there have no relation to projects and move them to more relevant places in `pull_requests.py` * update corresponding crons (and tests using those crons) as the methods have changed model, and the cron definitions thus need to be updated * split update to labels out of sending feedback comments while at it: labels are not used much during tests so their manipulation can be avoided; and labels are not as urgent as feedback so the crons can be quite a bit slower * move the project view out of `mergebot.xml` as well
2021-11-10 19:13:34 +07:00
<field name="code">model._check(True)</field>
[IMP] runbot_merge: remove "sync PRs", fetch unknown PRs The old "sync pr" thing is turning out to be a bust, while it originally worked fine these days it's a catastrophe as the v4 API performances seem to have significantly degraded, to the point that fetching all 15k PRs by pages of 100 simply blows up after a few hundreds/thousands. Instead, add a table of PRs to sync: if we get notified of a "compatible" PR (enabled repo & target) which we don't know of, create an entry in a "fetch jobs" table, then a cron will handle fetching the PR then fetching/applying all relevant metadata (statuses, review-comments and reviews). Also change indexation of Commit(sha) and PR(head) to hash, as btree indexes are not really sensible for such content (the ordering is unhelpful and the index locality is awful by design/definition).
2018-06-21 14:55:14 +07:00
<field name="interval_number">1</field>
<field name="interval_type">minutes</field>
<field name="numbercall">-1</field>
<field name="doall" eval="False"/>
</record>
[ADD] runbot_merge: warning that a ready PR is linked to a non-ready one People get surprised/worried that their ready PR never gets picked up, but it's because there is a non-ready (either unreviewed or failing CI) pull request linked to it. This aims to at least warn them of the issue.
2018-10-15 21:19:29 +07:00
<record model="ir.cron" id="check_linked_prs_status">
<field name="name">Warn on linked PRs where only one is ready</field>
<field name="model_id" ref="model_runbot_merge_pull_requests"/>
<field name="state">code</field>
<field name="code">model._check_linked_prs_statuses(True)</field>
<field name="interval_number">1</field>
<field name="interval_type">hours</field>
<field name="numbercall">-1</field>
<field name="doall" eval="False"/>
</record>
[IMP] runbot_merge: extract commit validation to cron Before this, impacting a commit's statuses on the relevant PR or staging would be performed immediatly / inline with its consumption. This, however, is problematic if we want to implement additional processing like #87 (and possibly though probably not #52): webhook handlers should be kept short and fast, feeding back into github would not be acceptable. - flag commits as needing processing instead of processing them immediately, this uses a partial index as it looks like the recommended / proper way to index a boolean column in which one of the values is searched much more than the other (todo: eventually check if that actually does anythnig) - add a new cron for commits processing - alter tests so they use this new cron (mostly by migrating them to `run_crons` though not solely as some still need more detailed management to properly check intermediate steps) Fix an issue with closing a staged PR while at it (the "merging" tag would potentially never be removed).
2019-03-05 14:01:38 +07:00
<record model="ir.cron" id="process_updated_commits">
<field name="name">Impact commit statuses on PRs and stagings</field>
<field name="model_id" ref="model_runbot_merge_commit"/>
<field name="state">code</field>
<field name="code">model._notify()</field>
<field name="interval_number">1</field>
<field name="interval_type">minutes</field>
<field name="numbercall">-1</field>
<field name="doall" eval="False"/>
</record>
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
</odoo>
Reference in New Issue Copy Permalink