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
18.0-fix-timeout-xdo
runbot/runbot_merge/data/merge_cron.xml

80 lines
3.4 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>
[IMP] *: trigger-ify merge cron The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.
2024-07-31 14:40:53 +07:00
<field name="interval_number">6</field>
<field name="interval_type">hours</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="numbercall">-1</field>
<field name="doall" eval="False"/>
[IMP] *: crons tests running for better triggered compatibility Mergebot / forwardport crons need to run in a specific ordering in order to flow into one another correctly. The default ordering being unspecified, it was not possible to use the normal cron runner (instead of the external driver running crons in sequence one at a time). This can be fixed by setting *sequences* on crons, as the cron runner (`_process_jobs`) will use that order to acquire and run crons. Also override `_process_jobs` however: the built-in cron runner fetches a static list of ready crons, then runs that. This is fine for normal situation where the cron runner runs in a loop anyway but it's any issue for the tests, as we expect that cron A can trigger cron B, and we want cron B to run *right now* even if it hadn't been triggered before cron A ran. We can replace `_process_job` with a cut down version which does that (cut down because we don't need most of the error handling / resilience, there's no concurrent workers, there's no module being installed, versions must match, ...). This allows e.g. the cron propagating commit statuses to trigger the staging cron, and both will run within the same `run_crons` session. Something I didn't touch is that `_process_jobs` internally creates completely new environments so there is no way to pass context into the cron jobs anymore (whereas it works for `method_direct_trigger`), this means the context values have to be shunted elsewhere for that purpose which is gross. But even though I'm replacing `_process_jobs`, this seems a bit too much of a change in cron execution semantics. So left it out. While at it tho, silence the spammy `py.warnings` stuff I can't do much about.
2024-07-30 14:21:05 +07:00
<field name="priority">30</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
</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>
[IMP] *: trigger-ify staging cron The staging cron turns out to be pretty reasonable to trigger, as we already have a handler on the transition of a batch to `not blocked`, which is exactly when we want to create a staging (that and the completion of the previous staging). The batch transition is in a compute which is not awesome, but on the flip side we also cancel active stagings in that exact scenario (if it applies), so that matches. The only real finesse is that one of the tests wants to observe the instant between the end of a staging (and creation of splits) and the start of the next one, which because the staging cron is triggered by the failure of the previous staging is now "atomic", requiring disabling the staging cron, which means the trigger is skipped entirely. So this requires triggering the staging cron by hand.
2024-08-01 15:15:32 +07:00
<field name="interval_number">6</field>
<field name="interval_type">hours</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="numbercall">-1</field>
<field name="doall" eval="False"/>
[IMP] *: crons tests running for better triggered compatibility Mergebot / forwardport crons need to run in a specific ordering in order to flow into one another correctly. The default ordering being unspecified, it was not possible to use the normal cron runner (instead of the external driver running crons in sequence one at a time). This can be fixed by setting *sequences* on crons, as the cron runner (`_process_jobs`) will use that order to acquire and run crons. Also override `_process_jobs` however: the built-in cron runner fetches a static list of ready crons, then runs that. This is fine for normal situation where the cron runner runs in a loop anyway but it's any issue for the tests, as we expect that cron A can trigger cron B, and we want cron B to run *right now* even if it hadn't been triggered before cron A ran. We can replace `_process_job` with a cut down version which does that (cut down because we don't need most of the error handling / resilience, there's no concurrent workers, there's no module being installed, versions must match, ...). This allows e.g. the cron propagating commit statuses to trigger the staging cron, and both will run within the same `run_crons` session. Something I didn't touch is that `_process_jobs` internally creates completely new environments so there is no way to pass context into the cron jobs anymore (whereas it works for `method_direct_trigger`), this means the context values have to be shunted elsewhere for that purpose which is gross. But even though I'm replacing `_process_jobs`, this seems a bit too much of a change in cron execution semantics. So left it out. While at it tho, silence the spammy `py.warnings` stuff I can't do much about.
2024-07-30 14:21:05 +07:00
<field name="priority">40</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
</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] *: trigger-ify task queue type crons These are pretty simple to convert as they are straightforward: an item is added to a work queue (table), then a cron regularly scans through the table executing the items and deleting them. That means the cron trigger can just be added on `create` and things should work out fine. There's just two wrinkles in the port_forward cron: - It can be requeued in the future, so needs a conditional trigger-ing in `write`. - It is disabled during freeze (maybe something to change), as a result triggers don't enqueue at all, so we need to immediately trigger after freeze to force the cron re-enabling it.
2024-07-30 18:45:51 +07:00
<field name="interval_number">6</field>
<field name="interval_type">hours</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="numbercall">-1</field>
<field name="doall" eval="False"/>
[IMP] *: crons tests running for better triggered compatibility Mergebot / forwardport crons need to run in a specific ordering in order to flow into one another correctly. The default ordering being unspecified, it was not possible to use the normal cron runner (instead of the external driver running crons in sequence one at a time). This can be fixed by setting *sequences* on crons, as the cron runner (`_process_jobs`) will use that order to acquire and run crons. Also override `_process_jobs` however: the built-in cron runner fetches a static list of ready crons, then runs that. This is fine for normal situation where the cron runner runs in a loop anyway but it's any issue for the tests, as we expect that cron A can trigger cron B, and we want cron B to run *right now* even if it hadn't been triggered before cron A ran. We can replace `_process_job` with a cut down version which does that (cut down because we don't need most of the error handling / resilience, there's no concurrent workers, there's no module being installed, versions must match, ...). This allows e.g. the cron propagating commit statuses to trigger the staging cron, and both will run within the same `run_crons` session. Something I didn't touch is that `_process_jobs` internally creates completely new environments so there is no way to pass context into the cron jobs anymore (whereas it works for `method_direct_trigger`), this means the context values have to be shunted elsewhere for that purpose which is gross. But even though I'm replacing `_process_jobs`, this seems a bit too much of a change in cron execution semantics. So left it out. While at it tho, silence the spammy `py.warnings` stuff I can't do much about.
2024-07-30 14:21:05 +07:00
<field name="priority">60</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
</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>
[CHG] runbot_merge: move labels cron to triggered Missed it during the previous pass, probably because it's in the middle of `pull_requests.py`. It's a classic template for triggered crons since the model is just a queue of actions for the cron.
2024-10-22 15:50:09 +07:00
<field name="interval_type">hours</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="numbercall">-1</field>
<field name="doall" eval="False"/>
[IMP] *: crons tests running for better triggered compatibility Mergebot / forwardport crons need to run in a specific ordering in order to flow into one another correctly. The default ordering being unspecified, it was not possible to use the normal cron runner (instead of the external driver running crons in sequence one at a time). This can be fixed by setting *sequences* on crons, as the cron runner (`_process_jobs`) will use that order to acquire and run crons. Also override `_process_jobs` however: the built-in cron runner fetches a static list of ready crons, then runs that. This is fine for normal situation where the cron runner runs in a loop anyway but it's any issue for the tests, as we expect that cron A can trigger cron B, and we want cron B to run *right now* even if it hadn't been triggered before cron A ran. We can replace `_process_job` with a cut down version which does that (cut down because we don't need most of the error handling / resilience, there's no concurrent workers, there's no module being installed, versions must match, ...). This allows e.g. the cron propagating commit statuses to trigger the staging cron, and both will run within the same `run_crons` session. Something I didn't touch is that `_process_jobs` internally creates completely new environments so there is no way to pass context into the cron jobs anymore (whereas it works for `method_direct_trigger`), this means the context values have to be shunted elsewhere for that purpose which is gross. But even though I'm replacing `_process_jobs`, this seems a bit too much of a change in cron execution semantics. So left it out. While at it tho, silence the spammy `py.warnings` stuff I can't do much about.
2024-07-30 14:21:05 +07:00
<field name="priority">70</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
</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] *: trigger-ify task queue type crons These are pretty simple to convert as they are straightforward: an item is added to a work queue (table), then a cron regularly scans through the table executing the items and deleting them. That means the cron trigger can just be added on `create` and things should work out fine. There's just two wrinkles in the port_forward cron: - It can be requeued in the future, so needs a conditional trigger-ing in `write`. - It is disabled during freeze (maybe something to change), as a result triggers don't enqueue at all, so we need to immediately trigger after freeze to force the cron re-enabling it.
2024-07-30 18:45:51 +07:00
<field name="interval_number">6</field>
<field name="interval_type">hours</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="numbercall">-1</field>
<field name="doall" eval="False"/>
[IMP] *: crons tests running for better triggered compatibility Mergebot / forwardport crons need to run in a specific ordering in order to flow into one another correctly. The default ordering being unspecified, it was not possible to use the normal cron runner (instead of the external driver running crons in sequence one at a time). This can be fixed by setting *sequences* on crons, as the cron runner (`_process_jobs`) will use that order to acquire and run crons. Also override `_process_jobs` however: the built-in cron runner fetches a static list of ready crons, then runs that. This is fine for normal situation where the cron runner runs in a loop anyway but it's any issue for the tests, as we expect that cron A can trigger cron B, and we want cron B to run *right now* even if it hadn't been triggered before cron A ran. We can replace `_process_job` with a cut down version which does that (cut down because we don't need most of the error handling / resilience, there's no concurrent workers, there's no module being installed, versions must match, ...). This allows e.g. the cron propagating commit statuses to trigger the staging cron, and both will run within the same `run_crons` session. Something I didn't touch is that `_process_jobs` internally creates completely new environments so there is no way to pass context into the cron jobs anymore (whereas it works for `method_direct_trigger`), this means the context values have to be shunted elsewhere for that purpose which is gross. But even though I'm replacing `_process_jobs`, this seems a bit too much of a change in cron execution semantics. So left it out. While at it tho, silence the spammy `py.warnings` stuff I can't do much about.
2024-07-30 14:21:05 +07:00
<field name="priority">10</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
</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"/>
[IMP] *: crons tests running for better triggered compatibility Mergebot / forwardport crons need to run in a specific ordering in order to flow into one another correctly. The default ordering being unspecified, it was not possible to use the normal cron runner (instead of the external driver running crons in sequence one at a time). This can be fixed by setting *sequences* on crons, as the cron runner (`_process_jobs`) will use that order to acquire and run crons. Also override `_process_jobs` however: the built-in cron runner fetches a static list of ready crons, then runs that. This is fine for normal situation where the cron runner runs in a loop anyway but it's any issue for the tests, as we expect that cron A can trigger cron B, and we want cron B to run *right now* even if it hadn't been triggered before cron A ran. We can replace `_process_job` with a cut down version which does that (cut down because we don't need most of the error handling / resilience, there's no concurrent workers, there's no module being installed, versions must match, ...). This allows e.g. the cron propagating commit statuses to trigger the staging cron, and both will run within the same `run_crons` session. Something I didn't touch is that `_process_jobs` internally creates completely new environments so there is no way to pass context into the cron jobs anymore (whereas it works for `method_direct_trigger`), this means the context values have to be shunted elsewhere for that purpose which is gross. But even though I'm replacing `_process_jobs`, this seems a bit too much of a change in cron execution semantics. So left it out. While at it tho, silence the spammy `py.warnings` stuff I can't do much about.
2024-07-30 14:21:05 +07:00
<field name="priority">50</field>
[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>
[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>
[IMP] *: rely only on triggers to run statuses propagation The cron had been converted to using mostly triggers in 7cd9afe7f2ff2cbaaabe0ecf6eb364b55aaf8d60 but I forgot to update the *tests* to avoid explicitly triggering it.
2024-07-30 18:42:00 +07:00
<field name="interval_number">6</field>
<field name="interval_type">hours</field>
[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
<field name="numbercall">-1</field>
<field name="doall" eval="False"/>
[IMP] *: crons tests running for better triggered compatibility Mergebot / forwardport crons need to run in a specific ordering in order to flow into one another correctly. The default ordering being unspecified, it was not possible to use the normal cron runner (instead of the external driver running crons in sequence one at a time). This can be fixed by setting *sequences* on crons, as the cron runner (`_process_jobs`) will use that order to acquire and run crons. Also override `_process_jobs` however: the built-in cron runner fetches a static list of ready crons, then runs that. This is fine for normal situation where the cron runner runs in a loop anyway but it's any issue for the tests, as we expect that cron A can trigger cron B, and we want cron B to run *right now* even if it hadn't been triggered before cron A ran. We can replace `_process_job` with a cut down version which does that (cut down because we don't need most of the error handling / resilience, there's no concurrent workers, there's no module being installed, versions must match, ...). This allows e.g. the cron propagating commit statuses to trigger the staging cron, and both will run within the same `run_crons` session. Something I didn't touch is that `_process_jobs` internally creates completely new environments so there is no way to pass context into the cron jobs anymore (whereas it works for `method_direct_trigger`), this means the context values have to be shunted elsewhere for that purpose which is gross. But even though I'm replacing `_process_jobs`, this seems a bit too much of a change in cron execution semantics. So left it out. While at it tho, silence the spammy `py.warnings` stuff I can't do much about.
2024-07-30 14:21:05 +07:00
<field name="priority">20</field>
[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>
[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