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

271 lines
11 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>
[IMP] runbot_merge: split status configuration into own object Having the required statuses be a mere list of contexts has become a bit too limiting for our needs as it doesn't allow e.g. adding new required statuses on only some branches of a repository (e.g. only master), nor does it allow putting checks on only branches, or only stagings, which would be useful for overridable checks and the like, or for checks which only make sense linked to a specific revision range (e.g. "incremental" linting which would only check whatever's been modified in a PR). Split the required statuses into a separate set of objects, any of which can be separately marked as applying only to some branches (no branch = all branches). Fixes #382
2020-07-10 15:21:43 +07:00
<record id="form_repository" model="ir.ui.view">
<field name="name">Repository form</field>
<field name="model">runbot_merge.repository</field>
<field name="arch" type="xml">
<form>
<sheet>
<div class="oe_title">
<h1><field name="name"/></h1>
</div>
<group>
[ADD] runbot_merge: PR dashboard Provides a view of the "ongoing" state of a PR in order to more easily know what might be blocking / problematic.
2020-11-13 16:38:48 +07:00
<group>
<field name="group_id" string="Accessible to"/>
</group>
[IMP] runbot_merge: split status configuration into own object Having the required statuses be a mere list of contexts has become a bit too limiting for our needs as it doesn't allow e.g. adding new required statuses on only some branches of a repository (e.g. only master), nor does it allow putting checks on only branches, or only stagings, which would be useful for overridable checks and the like, or for checks which only make sense linked to a specific revision range (e.g. "incremental" linting which would only check whatever's been modified in a PR). Split the required statuses into a separate set of objects, any of which can be separately marked as applying only to some branches (no branch = all branches). Fixes #382
2020-07-10 15:21:43 +07:00
<group>
<field name="branch_filter"/>
</group>
</group>
<separator string="Required Statuses"/>
<field name="status_ids">
<tree editable="bottom">
<field name="context"/>
[FIX] runbot_merge: remove widget on branch_filter Apparently: * this requires a `model` option (makes sense) * this blows up in a list view (makes less sense)
2020-10-05 13:02:14 +07:00
<field name="branch_filter"/>
[IMP] runbot_merge: provide for statuses being only on PRs or stagings Requirement for odoo/runbot#376: one can't expect there being someone to override CI checks on stagings, so it only makes sense for checks on PRs, which in turns requires that there could be checks only required on PRs. Could also be useful for features like incremental linting / formatting, we may want to apply checks on PRs which filter on the lines modified, but not require the entire software be reformatted at once.
2020-07-10 17:55:39 +07:00
<field name="prs"/>
<field name="stagings"/>
[IMP] runbot_merge: split status configuration into own object Having the required statuses be a mere list of contexts has become a bit too limiting for our needs as it doesn't allow e.g. adding new required statuses on only some branches of a repository (e.g. only master), nor does it allow putting checks on only branches, or only stagings, which would be useful for overridable checks and the like, or for checks which only make sense linked to a specific revision range (e.g. "incremental" linting which would only check whatever's been modified in a PR). Split the required statuses into a separate set of objects, any of which can be separately marked as applying only to some branches (no branch = all branches). Fixes #382
2020-07-10 15:21:43 +07:00
</tree>
</field>
</sheet>
</form>
</field>
</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
<record id="runbot_merge_action_projects" model="ir.actions.act_window">
<field name="name">Projects</field>
<field name="res_model">runbot_merge.project</field>
<field name="view_mode">tree,form</field>
</record>
<record id="runbot_merge_action_prs" model="ir.actions.act_window">
<field name="name">Pull Requests</field>
<field name="res_model">runbot_merge.pull_requests</field>
<field name="view_mode">tree,form</field>
<field name="context">{'search_default_open': True}</field>
</record>
<record id="runbot_merge_search_prs" model="ir.ui.view">
<field name="name">PR search</field>
<field name="model">runbot_merge.pull_requests</field>
<field name="arch" type="xml">
<search>
<filter
name="open" string="Open"
domain="[('state', 'not in', ['merged', 'closed'])]"
/>
[IMP] runbot_merge: add number to PR search view The number is probably the most common search criteria for PRs (to track their status / issues). Having to go through custom filters to find one is a pain in the ass. Already done live by editing the view, but means it's getting lost every time the module gets updated. closes #73
2019-01-25 21:49:20 +07:00
<field name="number"/>
[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="author"/>
<field name="label"/>
<field name="target"/>
<field name="repository"/>
<field name="state"/>
<group>
<filter string="Target" name="target_" context="{'group_by':'target'}"/>
<filter string="Repository" name="repo_" context="{'group_by':'repository'}"/>
<filter string="State" name="state_" context="{'group_by':'state'}"/>
<filter string="Priority" name="priority_" context="{'group_by':'priority'}"/>
</group>
</search>
</field>
</record>
<record id="runbot_merge_tree_prs" model="ir.ui.view">
<field name="name">PR tree</field>
<field name="model">runbot_merge.pull_requests</field>
<field name="arch" type="xml">
<tree>
<field name="repository"/>
<field name="number"/>
<field name="target"/>
<field name="state"/>
</tree>
</field>
</record>
<record id="runbot_merge_form_prs" model="ir.ui.view">
<field name="name">PR form</field>
<field name="model">runbot_merge.pull_requests</field>
<field name="arch" type="xml">
<form>
<header/>
<sheet>
<div class="oe_title">
<h1>
<field name="repository"/>#<field name="number"/>
</h1>
</div>
<group>
<group>
<field name="target"/>
<field name="state"/>
<field name="author"/>
<field name="priority"/>
</group>
<group>
<field name="label"/>
<field name="squash"/>
</group>
</group>
<group>
<group colspan="4">
<field name="head"/>
<field name="statuses"/>
[ADD] runbot_merge: allow overriding statuses Adds an `override` mergebot command. The ability to override is set on an individual per-context per-repository basis, similar to but independent from review rights. That is, a given individual may be able to override the status X on repository A and unable to do so on repository B. Overrides are stored in the same format as regular statuses, but independent from them in order to persist them across builds. Only PR statuses can be overridden, statuses which are overridable on PRs would simply not be required on stagings. An alternative to implementing this feature in the mergebot would be to add it to individual status-generating tools on a per-need basis. Pros of that alternative: * display the correct status on PRs, currently the PR will be failing status-wise (on github) but correct as far as the mergebot is concerned * remove complexity from the mergebot Cons of that alternative: * each status-generating tool would have to implement some sort of ACL system * each status-generating tool would have to receive & parse PR comments * each status-generating tool would have to maintain per-pr state in order to track overrides Some sort of helper library / framework ought make that rather easy though. It could also be linked into the central provisioning system thing. Closes #376
2020-07-14 15:06:07 +07:00
<field name="overrides"/>
[ADD] runbot_merge: a merge bot No actual dependency on runbot, should be usable completely independently.
2018-03-14 16:37:46 +07:00
</group>
</group>
<group>
<group colspan="4" string="Message">
<field name="message" nolabel="1"/>
</group>
</group>
<group>
<group colspan="4" string="Delegates">
<field name="delegates" nolabel="1">
<tree>
<field name="name"/>
<field name="github_login"/>
</tree>
</field>
</group>
</group>
</sheet>
</form>
</field>
</record>
<record id="runbot_merge_action_stagings" model="ir.actions.act_window">
<field name="name">Stagings</field>
<field name="res_model">runbot_merge.stagings</field>
<field name="view_mode">tree,form</field>
[IMP] runbot_merge: stagings views * fix "Active" filter which was not updated when the active field was added * properly enable it by default instead of relying on active_test * disable active_test on the Stagings action, otherwise the batches are not visible in the staging once the staging and batches have been disabled
2018-10-10 22:30:39 +07:00
<field name="context">{'search_default_active': True, 'active_test': False}</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>
<record id="runbot_merge_search_stagings" model="ir.ui.view">
<field name="name">Stagings Search</field>
<field name="model">runbot_merge.stagings</field>
<field name="arch" type="xml">
<search>
<filter string="Active" name="active"
[IMP] runbot_merge: stagings views * fix "Active" filter which was not updated when the active field was added * properly enable it by default instead of relying on active_test * disable active_test on the Stagings action, otherwise the batches are not visible in the staging once the staging and batches have been disabled
2018-10-10 22:30:39 +07:00
domain="[('active', '=', True)]"/>
[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="state"/>
<field name="target"/>
<group>
<filter string="Target" name="target_" context="{'group_by': 'target'}"/>
</group>
</search>
</field>
</record>
<record id="runbot_merge_tree_stagings" model="ir.ui.view">
<field name="name">Stagings Tree</field>
<field name="model">runbot_merge.stagings</field>
<field name="arch" type="xml">
<tree>
<field name="target"/>
<field name="state"/>
</tree>
</field>
</record>
[ADD] runbot_merge: button to manually cancel stagings This is somewhat less useful with runbot's fail-fast as a runbot failure (false positive or not) will now very quickly trigger an end to the current staging. Still, could be of use. closes #89
2019-03-01 23:29:37 +07:00
<record id="runbot_merge_form_stagings" model="ir.ui.view">
<field name="name">Stagings Form</field>
<field name="model">runbot_merge.stagings</field>
<field name="arch" type="xml">
<form>
[FIX] runbot_merge: cancel button on staging * split action_cancel (UI button) from cancel (internal): since the xhr mapping is weird, if there are available args the mapper thinks it should pass the call context as reason which is unexpected * make cancel a no-op when called on already inactive stagings * make cancel work when called on multiple statgings * make computing the active staging work properly in an active_test=False context (e.g. when it's interacted with from the form view because that comes from the list view which is active_test=False, probably so we can see not just the stagings but recursively see deactivated batches in deactivated stagings) * don't show the cancel button on inactive stagings
2019-08-27 17:28:53 +07:00
<field name="active" invisible="1"/>
[ADD] runbot_merge: button to manually cancel stagings This is somewhat less useful with runbot's fail-fast as a runbot failure (false positive or not) will now very quickly trigger an end to the current staging. Still, could be of use. closes #89
2019-03-01 23:29:37 +07:00
<header>
[FIX] runbot_merge: cancel button on staging * split action_cancel (UI button) from cancel (internal): since the xhr mapping is weird, if there are available args the mapper thinks it should pass the call context as reason which is unexpected * make cancel a no-op when called on already inactive stagings * make cancel work when called on multiple statgings * make computing the active staging work properly in an active_test=False context (e.g. when it's interacted with from the form view because that comes from the list view which is active_test=False, probably so we can see not just the stagings but recursively see deactivated batches in deactivated stagings) * don't show the cancel button on inactive stagings
2019-08-27 17:28:53 +07:00
<button type="object" name="action_cancel" string="Cancel" class="oe_highlight"
attrs="{'invisible': [('active', '=', False)]}"
/>
[ADD] runbot_merge: button to manually cancel stagings This is somewhat less useful with runbot's fail-fast as a runbot failure (false positive or not) will now very quickly trigger an end to the current staging. Still, could be of use. closes #89
2019-03-01 23:29:37 +07:00
</header>
<sheet>
<group>
<group>
<field name="target"/>
<field name="state"/>
<field name="reason"/>
</group>
<group>
<field name="staged_at"/>
</group>
</group>
[IMP] runbot_merge: show heads on stagings Stagings have a "statuses" field which was shown but useless (as it's a binary), they also have a "heads" field which only provides a mapping of repository names to commits. This change provides the staging heads as a commits m2m. Fixes #178
2019-08-26 21:25:16 +07:00
<group string="Heads">
<field name="head_ids" colspan="4" nolabel="1">
<tree>
<field name="sha"/>
<field name="statuses"/>
</tree>
</field>
</group>
<group string="Batches">
<field name="batch_ids" colspan="4" nolabel="1">
[ADD] runbot_merge: button to manually cancel stagings This is somewhat less useful with runbot's fail-fast as a runbot failure (false positive or not) will now very quickly trigger an end to the current staging. Still, could be of use. closes #89
2019-03-01 23:29:37 +07:00
<tree>
<field name="prs"/>
</tree>
</field>
</group>
</sheet>
</form>
</field>
</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
[IMP] runbot_merge: add action for planned PR fetches
2018-09-03 22:53:43 +07:00
<record id="runbot_merge_action_fetches" model="ir.actions.act_window">
<field name="name">PRs to fetch</field>
<field name="res_model">runbot_merge.fetch_job</field>
<field name="view_mode">tree</field>
<field name="context">{'default_active': True}</field>
</record>
<record id="runbot_merge_search_fetches" model="ir.ui.view">
<field name="name">Fetches Search</field>
[FIX] runbot_merge: wrong model name in a view
2018-09-10 17:32:33 +07:00
<field name="model">runbot_merge.fetch_job</field>
[IMP] runbot_merge: add action for planned PR fetches
2018-09-03 22:53:43 +07:00
<field name="arch" type="xml">
<search>
<filter string="Active" name="active"
domain="[('active', '=', True)]"/>
<field name="repository"/>
<field name="number"/>
</search>
</field>
</record>
<record id="runbot_merge_tree_fetches" model="ir.ui.view">
<field name="name">Fetches Tree</field>
<field name="model">runbot_merge.fetch_job</field>
<field name="arch" type="xml">
<tree>
<field name="repository"/>
<field name="number"/>
</tree>
</field>
</record>
[IMP] runbot_merge: overridable CI Convert overridable CI to an m2m from partners, it's significantly more convenient to manipulate as multiple users can (and likely will) have access to the same overrides, add a name_search so the override is easy to find from a partner, and provide a view for the overrides (with partners as tags). Also make the repository optional on CI overrides. Fixes #420
2020-11-12 19:17:37 +07:00
<record id="runbot_merge_action_overrides" model="ir.actions.act_window">
<field name="name">CI / statuses overrides</field>
<field name="res_model">res.partner.override</field>
</record>
<record id="runot_merge_tree_overrides" model="ir.ui.view">
<field name="name">Overrides List</field>
<field name="model">res.partner.override</field>
<field name="arch" type="xml">
<tree editable="bottom">
<field name="context"/>
<field name="repository_id"/>
<field name="partner_ids" widget="many2many_tags"/>
</tree>
</field>
</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
<menuitem name="Mergebot" id="runbot_merge_menu"/>
<menuitem name="Projects" id="runbot_merge_menu_project"
parent="runbot_merge_menu"
action="runbot_merge_action_projects"/>
<menuitem name="Pull Requests" id="runbot_merge_menu_prs"
parent="runbot_merge_menu"
action="runbot_merge_action_prs"/>
<menuitem name="Stagings" id="runbot_merge_menu_stagings"
parent="runbot_merge_menu"
action="runbot_merge_action_stagings"/>
[IMP] runbot_merge: add action for planned PR fetches
2018-09-03 22:53:43 +07:00
<menuitem name="Fetches" id="runbot_merge_menu_fetches"
parent="runbot_merge_menu"
action="runbot_merge_action_fetches"/>
[IMP] runbot_merge: overridable CI Convert overridable CI to an m2m from partners, it's significantly more convenient to manipulate as multiple users can (and likely will) have access to the same overrides, add a name_search so the override is easy to find from a partner, and provide a view for the overrides (with partners as tags). Also make the repository optional on CI overrides. Fixes #420
2020-11-12 19:17:37 +07:00
<menuitem name="Configuration" id="runbot_merge_menu_configuration" parent="runbot_merge_menu"/>
<menuitem name="CI Overrides" id="runbot_merge_menu_configuration_overrides"
parent="runbot_merge_menu"
action="runbot_merge_action_overrides"/>
[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